ICKP_DEADLINK meaning, and recovery.

[roelfdiedericks]

I have forked KCP-Go, to fiddle with some changes, and exposed the kcp.state as GetState so that I can see if a connection is "dead" and then reestablish a connection.

I also tweaked the IKCP_DEADLINK to a value of 200, as it appears that in my high throughput application 20 is way too litle, and blocks the connection under high throughput, which I can detect using the new GetState function.

However I'm still rather confused as it what "dead" is, and what the definition of it is. It seems to happen every so often (even with ICKP_DEADLINK=200) under high throughput conditions on mobile connections.

Is there a way for KCP to recover from this condition? As it seems that in DEADLINK state, the server is still trying to send some packets, but the client is refusing to transmit, until I detect DEADLINK, and reconnect on a new conversation.

I have confirmed that the "server" is still sending packets using tcpdump, but the client stops transmitting.

I'm using KCP in Turbo mode, with 128 send/recv buffers. No encryption and no FEC.

[roelfdiedericks]

My issue seemed to be related to the MTU on the mobile networks, after reducing MTU the condition no longer occurs. Would still like some clarification on DEADLINK however.

[xtaci]

Oh， that mean if a segment has been retransmitted for over '''DEADLINK ''' times, the kcp protocol marks the protocol as dead.

But it seems that golang implementation simply ignores this state.

[xtaci]

It's a MARK of death link, set based on experienece. I recommend using upper layer Read/Write timeout.

[roelfdiedericks]

Thank you. I have implemented read/write deadlines to handle these conditions rather.

[roelfdiedericks]

Closing.