kcp

kcp copied to clipboard

通过定时器调用的ikcp_update, 如果在ikcp_update前判断一下waitsnd 和ackcount是否都为0，是则停止调用ikcp_update且从定时器中删除。 当下次调用ikcp_input或者ikcp_send后，再调用ikcp_update并加入定时器。 这么做有什么隐患吗？

skymym

建议根据接受到的frg 如果比rcvWnd大的话,需要动态调节接受窗口大小.否则无法组装包.

wangjing112

ikcp_input函数接口是否应该添加current变量，准确获取当前时间戳？

3

函数int ikcp_input(ikcpcb* kcp, const char* data, long size)中调用kcp->current来获取当前时间戳，但是这个kcp->current可能和真实的时间戳存在偏差，所以是否应该在ikcp_input接口改成int ikcp_input(ikcpcb* kcp, IUINT32 current ,const char* data, long size)来获取准确的时间戳呢？

Alan-yly

源码中没有定义IKCP_FASTACK_CONSERVE宏导致的重复快重传问题

2

在ikcp_parse_fastack函数里发现如果不定义IKCP_FASTACK_CONSERVE宏，会导致已经重传的报文的报文被反复触发快重传，比如：发送端A报文已经重传了，之后发送端收到大于A报文编号的几个报文的ack，那么这些ack又会导致快重传A报文。 

Alan-yly

KCP在高延迟环境下怎样使用才能满足大流量，而不是快速响应？

3

我们需要同时工作在TCP和UDP协议中，所以选择了使用KCP，但是我的软件中还需要传输文件，我测试了在高延迟（1s）环境中，TCP协议、2048的窗口也只能达到400k左右的速度，还经常出现传输中断，ikcp_input后KCP再无任何响应。请问在高延迟环境中，只要求大流量而不要求快速响应我应该怎么使用呢？ 无延迟环境测试为16M/S

haozia816

使用check机制并不能使cpu使用率下降

5

您好，这一段我认为有问题，因为ikcp_check返回的时间戳永远小于kcp->ts_flush，而ikcp_update只会当kcp->current大于kcp->ts_flush时才会调用ikcp_flush，所以ikcp_check并不能降低ikcp_flush的调用频率，而所有cpu消耗主要集中在ikcp_flush中，所以使用check机制并不能使kcp的cpu消耗下降。

Alan-yly

kcp大带宽传输和发送队列长度问题

1

1. kcp 是不是无法传输大带宽，比如1000MBps ，如果能传输，是不是得修改发送和接收窗口大小，搞大点？ 2. 正如文中所说：kcp对发送queue 没有做长度的限制，那么如果存在这种场景：发送方首先开机了，不停的在往发送queue里面塞数据包，但是由于接收方还没开机，发送方就无法探测到对端的接收窗口，导致发送queue 无法太快的 往snd_buf里面送， 在这种情况下：岂不是发送queue 会一直无限制的增加，内存会堆爆的吧？ 3. 在重传策略中，如果这个包丢的次数大于kcp->dead_link ，作者会给kcp->state = (IUINT32)-1; 意思是这个包发了很多次了，还没有应答，但是作者的处理策略是仅仅给kcp->state赋值了-1； 并没有把这个包从snd_buf中移除吧，那这个包岂不是一直占着内存不释放？如果由于链路问题，存在大量这种包，岂不是会存在大量的死内存？

RobotFly

 ikcp_check函数返回的应该是kcp发送缓冲区中下一个需要发送的包的时间戳， 在这个时间点调用ikcp_update 只会更新kcp->current 并不会调用ikcp_flush函数，所以在这个时间点调用ikcp_update函数并不能将需要发送的报文发送出去，所以调用ikcp_update函数没用，应该调用ikcp_flush函数才行吧？或者在ikcp_update函数添加一个force_flush参数才行。

Alan-yly

就是接收和发送数据的过程。 我想做一个快速可靠的udp 传送，看上去kcp应该是选择。 我本想用udp 来实现，就是发多个udp编号包，一定时间或者包数后，发一个确定包，汇报收到包情况，没收到就重发。 不知怎么，收汇报有点不成功。 就是希望借鉴你的经验。

liwenz