well.james

堆栈行号 一般不重要的哇。一般都是看报错函数调用堆栈。可以考虑发布Release了；

> 确实没啥广告但是。。各种抖机灵的挺烦的。都是诚信发问的，然后来个戏谑的回答 你诚信发问 问题是没有闲人整体坐那 等着回答你问题。 除非付费，否则没必要。 我建议要么和楼上说的一样 就用github的issues就挺好的。

要怪就怪墙咯。全世界都没什么问题，就是国内特色。 可以试试myget

> RealTime PVP 有时候需要的是单MTU数据大小内最大序列号数据包有效 > > 例如玩家的位置，玩家可能发送了1，2，3，4，5，6一共6次位置。 > 而另一个玩家可能只收取到了1,3,5,6。当收到3的时候，因为比1大，因此3可以直接拿来使用，当2后来抵达后，会被忽略掉。客户端只关心刚收到的数据包的序号大于上一次数据包收到的序号。 > > 因此在这种情况下，并不要求重发。 > 请问KCP能够通过参数调整实现这种模式吗？ 所以 如果 6个包 最后两个包丢了 你要怎么处理？

> 你这个需求其实就是裸的udp的特性啊 原始 UDP的话，如果 6个包 最后两个包丢了 不好处理。因此这个情况可能要修改Kcp，来达到目的。

这个问题可能是这样。默认情况下还是假设全部重传。 但是如果受到 新包，那就丢弃前面的包，并且同时发送UNA（但是这个UNA发送的目的在于告知对方，只需要发送UNA后面的的包就行了，所以这块逻辑要改）。具体要搞个参数传给Kcp。 Ack也是同理。默认全部最新的几个包的Ack，对端受到Ack包后就可以丢弃Ack中最新ID之前的所有包了，只发后面的新包。

因为 const IUINT32 IKCP_WND_RCV = 128; // **must >= max fragment size** 而老代码貌似是 count 必须小于 max fragment size 有的版本直接是必须小于255 因为KCP使用1个byte 做分片ID。 即：如果大于最大分片能力，那么KCP无法发送这么大的包。

是否可以参考 https://github.com/v2ray/manual/blob/master/zh_cn/chapter_03/kcp.md https://www.v2ray.com/zh_cn/chapter_02/01_overview.html 思路进一步优化 KCP的能力呢？ 就好像 传说中的FastTcp 一样。。。。 鱼和熊掌 尽可能地兼得。

谢谢 老大回复 但是 不正是 流氓了那么一点点 所以 KCP和 fasttcp 之类的才能脱颖而出....慢慢流行.... 当然啦 咱也不能抄别人的成果，何况对方也没主动贡献代码。 就当我没说吧 其实我还是够用就行了 加油吧 老大，希望KCP 越来越好!

> 更小的协议头 > > 原生 KCP 协议使用了 24 字节的固定头部，而 mKCP 修改为数据包 18 字节，确认（ACK）包 12 字节。 更小的头部有助于躲避特征检查，并加快传输速度。 > 另外，原生 KCP 的单个确认包只能确认一个数据包已收到，也就是说当 KCP 需要确认 100 个数据已收 到时，它会发出 24 \* 100 = 2400...