Open gengzm opened 3 years ago
对的,没错,是这样,你可以自己把接收窗口设置大一点,或者你自己实现一个拆包拼包的逻辑。
作者你好。窗口不可能无限设大。拆包拼包是说把一个大文件(比如几兆上百M的拆分成不大于窗口份数)然后依次发送和接收?接收完毕后(接收128次后),似乎"窗口满了",如何“刷新”/“清空”窗口(清理发送端还是接收端)?原作者您的example里面也是128的窗口,在同一个循环体内部发送和接收,确是可以无上限ikcp_recv的。
直接把文件拆分成 1KB 一个包。
作者你好。窗口不可能无限设大。拆包拼包是说把一个大文件(比如几兆上百M的拆分成不大于窗口份数)然后依次发送和接收?接收完毕后(接收128次后),似乎"窗口满了",如何“刷新”/“清空”窗口(清理发送端还是接收端)?原作者您的example里面也是128的窗口,在同一个循环体内部发送和接收,确是可以无上限ikcp_recv的。
是的,为什么呢,假如在外面设置了这个拆包分包逻辑,为什么KCP里还有拆包分包呢?KCP里面不会把接收到的数据清除掉留给下一个序号的数据嘛,很疑惑
感觉作者理解错你想问的了,你的意思是接收了128次后后面的数据就接收不了了,但是作者写的测试的例子可以一直接收,而不是一个包超过窗口大小就接不了
时间太久了,有点不记得但是的想法。也是我提问没有描述清楚,应是你说的,假设有1万条消息,接受128条消息后,后续消息没有被接受了。
时间太久了,有点不记得但是的想法。也是我提问没有描述清楚,应是你说的,假设有1万条消息,接受128条消息后,后续消息没有被接受了。
这个要在客户端接收服务端的ACK包然后推进kcp里,才能把snd_buf的窗口往后移,就是把收到ACK包的数据从缓存中清除,就能发送新数据
时间太久了,有点不记得但是的想法。也是我提问没有描述清楚,应是你说的,假设有1万条消息,接受128条消息后,后续消息没有被接受了。 您没有在客户端进行udp的recvfrom然后input进kcp处理ACK包
请教如下问题 代码里面有KCP传消息和纯UDP传消息的部分 问题一:为什么我写的KCP测试只能接收窗口大小条消息,超过了无法接收。(本代码是只能接收128条) 问题二:感觉KCP传递的效率明显低于UDP