服务端重启后链路无法恢复

[lvyangdev]

• 因为服务端重启，重启后收到数据通过ikcp_parse_data中if (seg->sn == kcp->rcv_nxt && kcp->nrcv_que < kcp->rcv_wnd)判断入队列，此时conv一致，可惜的是seg->sn是之前递增的值，kcp->rcv_nxt将始终为0. 导致数据未入rcv_queue相当于未真正“接收”，因为ikcp_recv中的 if (iqueue_is_empty(&kcp->rcv_queue)) return -1;

• 那么此时同步sn只能在客户端新建kcp对象吗？这个意思是否只能是业务层通过类似心跳的机制判断此时的服务器数据未真正接收（网卡收到了但是业务层未收到），然后重连？

[skywind3000]

废话，你服务端重启了，原有 tcp 连接还能接着用么？

[lvyangdev]

废话，你服务端重启了，原有tcp连接还能用么？

业务层不通过类似心跳或确认机制的话不知道服务器重启了KCP连接不能用了啊。举个例子，kcp通道转发数据，此时解决这个问题需要重启kcp通道客户端，还不是说原客户端自己重连就能解决的。
所以我想问的是，KCP服务器重启了，因为是UDP无状态的，KCP客户端还是之前处理正常发数据到服务器，此时重启后的服务器是不是能知道自己重启了，那这个“服务区重启了状态丢了“的事件，在KCP底层能通知到KCP客户端吗？使其KCP客户端”重连“恢复链路。
尽管服务器重启，但UDP数据还是能正常收发，就是上层拿不到数据。上层拿不到，只能通过业务层判断，这很难用啊，你以TCP举例，问题是TCP断了，对端能知道断连事件啊，KCP对端不知道”断开“事件啊。

[skywind3000]

你别搞笑了，UDP 没状态，KCP 是有状态的啊；就像 IP 没状态，TCP 是有状态的啊；TCP 怎么处理 KCP 就怎么处理；服务器都重启了，你凭啥想指望旧的客户端 KCP 对象还可以同新的服务端 KCP 对象通信？有点基础知识行不行，两边全部重建新的 KCP 对象再连接；

[lvyangdev]

你别搞笑了，UDP 没状态，KCP 是有状态的啊；就像 IP 没状态，TCP 是有状态的啊；TCP 怎么处理 KCP 就怎么处理；服务器都重启了，你凭啥想指望旧的客户端 KCP 对象还可以同新的服务端 KCP 对象通信？有点基础知识行不行，两边全部重建新的 KCP 对象再连接；

今天用了你的库，写的非常棒，遇到了实实在在的问题，也看了代码，问题描述的也很清楚，我两次发言问的是：
1、如何确定“断了”，好进行重连。目前是数据未入rcv_queue队列。（上层读回调起不了作用，我只能通过“服务器上层拿不到数据，对应客户端也收不到数据”这种异常来判断（抓包有报文交互），问的是“只能在客户端新建kcp对象？是否只能是业务层通过类似心跳的机制判断此时的服务器数据未真正接收（网卡收到了但是业务层未收到），然后重连？”。你要不要看看你回答得什么，你可以回答是或者否，而不是来句“废话”再加一句反问，我当然知道要重连）。
2、KCP客户端是否有自主”重连“恢复链路的可能性（很明显不是你说的“指望旧的客户端 KCP 对象还可以同新的服务端 KCP 对象通信”，我都已经提到”在客户端新建kcp对象“了，我始终表达的是我遇到了”服务器上层收不到数据，客户端也收不到，数据被丢了“的问题。或许是我用的不对。）。

[skywind3000]

心跳不是 kcp 的事情，请自己在连接层增加 UDP 心跳，自己判断断线。

[lvyangdev]

心跳不是 kcp 的事情，请自己在连接层增加 UDP 心跳，自己判断断线。

好的，谢谢。