szh
szh
这里应该是 if (count >= 256) return -2; 才对吧，frg字段只有一个字节。
没有组装成完整数据。可以自己写解码器实现。
新的版本已经可以合并数据分段了
1. conv是会话id。conv需要外部进行指定。例子中是hard code。实际使用中，可以客户端与服务器端进行协商。 2. 包模式是会保留数据包的边界。会收到所有分片后才返回给外部。流模式没有这些。现在kcp-netty在包模式下，并没有将所有分片合成到一个ByteBuf里，而是将每个分片的ButeBuf都调用了一次channelRead，并在最后调用了一次channelReadComplete，以此来表示一个数据包的边界。我考虑之后可以增加一个开关，用来控制是否将数据合并到一个ByteBuf中。
是的，可以在外部用tcp或者udp进行协商。 另外，kcp-netty也确实根据channel.remoteAddress()保存了会话。
我这边使用时是通过tcp来进行协商的，conv是服务器端分配的，通过tcp告诉客户端，所以不会重复。把UkcpChannelOption.UKCP_AUTO_SET_CONV设置为true，就是为了先暂时接受客户端传过来的conv，然后消息传到上层，由服务器端上层逻辑判断conv是否合法（也就是判断conv是否与之前分配的一致）。
应该是连接断开导致抛出异常。
@Slive 加个开关忽略掉输入错误怎么样？
考虑之后可以做个开关控制是用remote address，还是用conv进行channel管理。
实际上这里并没有建立连接的过程，就只有读写，所以用WorkGroup就够了，没有BossGroup。