咨询关于conv值和stream模式的问题

[szhnet]

咨询关于conv值和stream模式的问题

[szhnet]

1. conv是会话id。conv需要外部进行指定。例子中是hard code。实际使用中，可以客户端与服务器端进行协商。
2. 包模式是会保留数据包的边界。会收到所有分片后才返回给外部。流模式没有这些。现在kcp-netty在包模式下，并没有将所有分片合成到一个ByteBuf里，而是将每个分片的ButeBuf都调用了一次channelRead，并在最后调用了一次channelReadComplete，以此来表示一个数据包的边界。我考虑之后可以增加一个开关，用来控制是否将数据合并到一个ByteBuf中。

[caoli5288]

conv写死，serverchannel里根据clientsocket进行管理在大部分场景下是没有问题的。
client端用一个socket去handle多个kcp会话这种做法估计不存在。

[yellowb]

Hi @szhnet

conv是会话id。conv需要外部进行指定。例子中是hard code。实际使用中，可以客户端与服务器端进行协商

请问关于“协商”，是在什么时候/什么地方进行？因为我看demo里都是在channelActive函数中set的，那么在channelActive之前Server/Client应该怎么协商？

Hi @caoli5288

你的意思是指Server和所有Cilent都写死一个conv是没问题的吗？

[caoli5288]

@yellowb 在kcp连接建立之前进行协商，用tcp，或者raw udp，或者其他协议如http。

仅限于kcp-netty的实现，conv写死是没问题的，因为kcp-netty根据channel.remoteAddress()保存会话。

[szhnet]

是的，可以在外部用tcp或者udp进行协商。
另外，kcp-netty也确实根据channel.remoteAddress()保存了会话。

[dingzhichao]

=

是的，可以在外部用tcp或者udp进行协商。

@szhnet 作者你好，请问能给出udp协商的 例子吗

[medusar]

Hi @szhnet

conv是会话id。conv需要外部进行指定。例子中是hard code。实际使用中，可以客户端与服务器端进行协商

请问关于“协商”，是在什么时候/什么地方进行？因为我看demo里都是在channelActive函数中set的，那么在channelActive之前Server/Client应该怎么协商？

Hi @caoli5288

你的意思是指Server和所有Cilent都写死一个conv是没问题的吗？

我也有同样的疑问，看例子中是channelActive的时候设置了conv,但在实际应用中，此时服务端并不知道这个链接对应的客户端的conv的值，想问下楼主解决了这个问题了吗？

[caoli5288]

@medusar

服务端并不知道这个链接对应的客户端的conv的值

你可以把这个值存在channel的metadata里。虽然我并不知道这么做有什么用。前文我已经解释过了，kcp-netty根据channel.remoteAddress()保存会话，事实上你在使用tcp时也是根据remoteAddress，存在conv只是因为udp本身并没有会话这种逻辑上的概念，你可以事实上复用端口开多个会话，但是为什么要这么做呢？

[medusar]

@caoli5288 恩，可能暂时我们也不会使用conv这个字段

[medusar]

发现有个UkcpChannelOption.UKCP_AUTO_SET_CONV参数，服务端设置该参数，可以不需要提前设置conv,直接读取客户端传递过来的conv

[gdpencil]

服务端用childOption(UkcpChannelOption.UKCP_AUTO_SET_CONV, true)，客户端随机一个数值conv。只要客户端前后两次端口值和conv值不是一样即没问题。两个随机值都相同的可能性太小，理论上没问题。

[szhnet]

我这边使用时是通过tcp来进行协商的，conv是服务器端分配的，通过tcp告诉客户端，所以不会重复。把UkcpChannelOption.UKCP_AUTO_SET_CONV设置为true，就是为了先暂时接受客户端传过来的conv，然后消息传到上层，由服务器端上层逻辑判断conv是否合法（也就是判断conv是否与之前分配的一致）。

[medusar]

@szhnet 恩，感觉你这种方式才是正确的。也是KCP文档里推荐的方式。但是目前我们客户端觉得这样需要一个KCP一个TCP两套逻辑，比较复杂，所以就没有搞，只用了一套方案。

[TXYH1]

@caoli5288 大佬，有一个小问题。只根据remoteAddress标识会话是不是无法区分同一端口的前后两次连接。或者是旧报文的影响。就像是tcp即使有socket四元组后，也还是需要通过三次握手协商seq
仅限于kcp-netty的实现，conv写死是没问题的，因为kcp-netty根据channel.remoteAddress()保存会话。

[TXYH1]

我简单了解过一点kcp-go的实现。 看起来也是通过remoteaddr来保存一条会话。在此基础再比较conv的值是否变化来判断连接状态。 conv则单纯由客户端随机生成，没有协商过程。这是一种最佳实践吗？请问目前比较流行怎么用呢

[caoli5288]

RE: @TXYH1

只根据remoteAddress标识会话是不是无法区分同一端口的前后两次连接

所以为什么要复用同一个udp端口前后发起两次连接？

conv则单纯由客户端随机生成，没有协商过程。这是一种最佳实践吗？

这跟写死conv一样，都是讨巧的做法。最规范的做法是在kcp连接发起前，通过别的协议（如tcp）协商出一个conv出来，但规范不代表最佳，最佳实践这东西就看场景见仁见智了。

[TXYH1]

@caoli5288 感谢大佬的回复

所以为什么要复用同一个udp端口前后发起两次连接
我只是感觉会不会存在一些特殊情况，比如在一条链接结束后，又用同一个端口重新建立了一条，或者断开重连了，同一时间只有一条链接，但是前后是不同两条链接了，避免旧包的影响啥的。