gnblao
gnblao
> 这么牛逼…… 还是大佬牛逼，打造的wf生态，很好玩～～～ 感觉nginx之后，workflow的设计实现已经上了另一新阶段咯～向大佬学习～～
> 好家伙！我直呼好家伙！ 我看workflow代码的时候，好家伙！我也直呼好家伙！～～
> 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。 关于乱序的问题，考虑到已经在wfchannel->channel_fanout_msg_in里面进行重组了，重组的逻辑类似tcp数据重组，我在每条msg进来的时候加了个seq。以此为排序依据。排序在处理 chanel_send_one 逻辑里面，is_channel = 2表明异步或者有其他现场正在ing写，这次不写下次在写。这里又个逻辑写的时候“必须”一个个msg写操作。 最后一个问题加了CONN_STATE_ESTABLISHED，主要的逻辑这操作session 的in和out上
> > 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。 > > 关于乱序的问题，考虑到已经在wfchannel->channel_fanout_msg_in里面进行重组了，重组的逻辑类似tcp数据重组，我在每条msg进来的时候加了个seq。以此为排序依据。排序在处理 > > chanel_send_one 逻辑里面，is_channel = 2表明异步或者有其他现场正在ing写，这次不写下次在写。这里又个逻辑写的时候“必须”一个个msg写操作。 >...
> > > 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > > > > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > > > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > > > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。 > > > > >...
> 嗯嗯，wait这块，你也可以看看我们的WFConditional和WFResourcePool。WFResourcePool是对WFConditional的一种组织形式，但WFConditaionl也可以独立使用，通过WFTaskFactory产生，唤醒方调用它的signal操作就可以。 https://github.com/sogou/workflow/blob/master/docs/about-conditional.md 嗯嗯，其实WFCondition ， WFCondtask的逻辑我搬的websocket分支里面，当时改完下了，发现WFConditional和WFResourcePool已经有，功能还有点重复了=-=
> > 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。 > > 关于乱序的问题，考虑到已经在wfchannel->channel_fanout_msg_in里面进行重组了，重组的逻辑类似tcp数据重组，我在每条msg进来的时候加了个seq。以此为排序依据。排序在处理 > > chanel_send_one 逻辑里面，is_channel = 2表明异步或者有其他现场正在ing写，这次不写下次在写。这里又个逻辑写的时候“必须”一个个msg写操作。 >...
> > > > 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > > > > > > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > > > > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > > > > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。...
> 你好用户，你的代码真是惊艳到我们了，非常感谢参与我们生态开发！ 我看了一下修改的Communicator代码，有几个问题需要确认一下： > > * 你如何实现WebSocketFrame的保序问题？我们认为任何全双工通信，用户对帧的处理应该是严格有序的。所以我们之前websocket分枝才搞出CommChannel这个类，这个类里，所有的handle_in都是在一个线程上执行。但你现在的代码，好像还是走了msgqueue。这样两个handle之间好像是可以并行和乱序的。似乎有问题。 > * chanel_send_one似乎不能解决并发的问题。因为channel随时可能被关闭。如果你参考我们的CommChannel，这里我们只要established了，用户需要调用shutdown来主动关闭连接（哪怕对端已经关闭了）。在shutdown之前，都可以向channel send数据，当然send可能直接失败。这个地方我们的代码实现非常复杂。你现在的代码明显简单不少，我不太确定是不是严密。 > * 你现在每个frame的append返回1之后，都直接回到session::handle，然后重新启动session。最近，我们刚刚上线了一个模块，可能可以简化你的工作，不用让session回到handle，而是每条消息都可以被回调，并且保序（在poller线程里）。这个模块 是[PackageWrapper](https://github.com/sogou/workflow/blob/master/src/protocol/PackageWrapper.cc)。原理是我们的消息是可以做协议叠加的，比如SSLWrapper就是一种协议叠加器。而对于WebSocketet一个channel上的读，可以认为是一堆frame的叠加。每个frame的append返回1之后，wrapper调用next操作得到下一个frame，传输可以断续进行，无需回到session的handle。这个协议叠加器，也可以完美解决所谓粘包问题。你大概看一下这个，应该能很快理解。 想了一下，关于shutdown的问题，之前逻辑是依据read = 0/timeout/ send error 来被动执行的。缺乏主动shutdown的场景，刚刚加了一下直接利用poller_del来shutdown。这样的话，代码改动比较少，也能复用wf架构close fd的逻辑。大佬，有空闲的话，拍拍🧱～～
> CommChannel的shutdown主要是为了解决竞争问题，因为send的一瞬间，你不能确定连接会不会被关闭并释放。所以，只要连接建立成功，需要在上面增加一个ref，在shutdown时减去。这样无论如何不会出现send时连接对象不存在的问题。 嗯嗯，我在wfchannel中也引入的类似的做法。复用connEntry中ref，在channel也引入了一个ref（作为msg级别的）