关于 socketchannel 的 padding 模式有些疑问

[t0350]

socketchannel 使用 padding 模式发包时，这个时候包走的低优先级通道。这样处理的话，似乎 dispatch_by_order 不能保证按顺序 dispatch？
比如像这样的情况：

channel:request(req1, resp1, padding)   -- 1
channel:request(req2, resp2, padding)   -- 2

在 1 执行后，唤醒 dispatch 逻辑，这个时候取得了 resp1，而可能 req1 还未发送出去，实际处理了 resp2 的 response？

目前 skynet 里只有 redis 使用了 dispatch_by_order 并且没有使用 padding 模式。只是同事看代码反馈到这里可能有问题？

[cloudwu]

对的。这里用 lwrite 有问题，不仅仅是 response 乱序的问题。而是 padding 是分次发送的，可能和正常 write 交错。

不过上面的例子反而不会出问题。因为，同一个coroutine 发 request 会等待 response 后才发下一个。

出问题应该是在多 coroutine 交错使用 padding 和无 padding 的情况。

明天我改成用 write 。

[cloudwu]

重新看了一下。padding 模式是为 cluster 加的。它可以有效阻止过大的 cluster 请求阻塞通道。它其实只能工作在 session 模式下。因为 padding 的每个 part 都包含有 session ，所以没有乱序的问题。

我想这个问题最好是在文档中补充，代码就不加 assert 了。

似乎 order 模式也没有必要使用 padding 模式，因为 socket 的 write 本身就支持传 table 了。如果选用 padding 的唯一理由就是希望分包，而分包对 order 模式是没有意义的。

[t0350]

也可以。文档有相关说明就好了。by order 的形式应该也比较少。

另外使用 lwrite 虽然能不阻塞通道，但也造成了乱序（非 response 分包后交错），这样有的业务其实是依赖保序的，这个云风建议是业务自己处理好吗？

[cloudwu]

lwrite 本身是保证次序的，且每个调用本身的数据不会被分割。同一个请求分多次 lwrite 是不破坏次序的。padding 中每个 part 都需要带 session 可以独立解析，不要求连续。

[t0350]

我指的是说这个情况。

cluster 间的请求大部分会按调用次序排序，即先发出的请求或推送先到。但也有例外的情况。当发送包单个超过 32k 时，包会被切分成多块传输，大的包必须等到所有块传输完毕，在这种情况下，大包的请求逻辑上先发出，可能后收到。回应也有这种可能。

https://github.com/cloudwu/skynet/wiki/Cluster#cluster-%E9%97%B4%E7%9A%84%E6%B6%88%E6%81%AF%E6%AC%A1%E5%BA%8F-message-order-between-clusters

[cloudwu]

我觉得这是无关的问题。 session 模式下，所有请求都被看成是独立的次序无关的，不需要保证不同 session 的请求的次序。