Ye Li

You may also think of it as quick control protocol, where K stands for quick. On Sun, Mar 20, 2022 at 6:38 PM caoli5288 ***@***.***> wrote: > Kuai Control Protocol...

原文中的理解应该是有误的，与链路层ARQ的Go-back-N混淆了。 首先，如果TCP开启了SACK（Selective ACK），则就是选择性重传。关于SACK，这篇文章图文并茂，解释得很清楚： https://www.geeksforgeeks.org/selective-acknowledgments-sack-in-tcp/ 其次，即使TCP没有开启SACK，它也并不会重传丢失的包（称为队头分组）以后的全部数据。丢包发生后，一方面，TCP发送端仍然是依据具体拥塞控制算法，根据收到的ACK分组数调整拥塞窗口CWND；另一方面，当连续收到3个重复ACK时，Fast Retransmit机制会触发对队头分组的重传。在完成队头分组的重传后：1）如果CWND允许（即大于在外分组数），会继续发送新的分组；2）停滞发送等待新的ACK到来；3）长时间未收到对队头分组的确认将触发RTO到时。 所以TCP没有SACK时，只是包的恢复会延后，并不会盲目重发队头分组后面那些未被确认的分组。 On Sat, Sep 24, 2022 at 9:03 PM thiscallaname ***@***.***> wrote: > 我也有这个疑问， 希望有人解答 > > — > Reply to this email directly,...

Thanks for your interest. We indeed are interested to port the project to C++ or golang, which should be able to considerably improve the performance. But currently we do not...

> 尝试过一对多的时候，限制仅一个设备ack，但是组播每个设备的丢包率是不一样的，每个设备收到的数据不一样，所以次方法行不通 看看喷泉码是不是符合你的要求。kcp用的是块码（block code），丢包率不同的组播场景下，很难做码率自适应。

> 他都组播了，哪里来的码率自适应。 他的场景下各个设备有不同的丢包率。他的意思就是想要组播时也能码率自适应。我的意思是，块码的机制难以在组播场景下实现码率自适应。