Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICKP_DEADLINK meaning, and recovery. #275

Open
roelfdiedericks opened this issue Sep 3, 2024 · 5 comments
Open

ICKP_DEADLINK meaning, and recovery. #275

roelfdiedericks opened this issue Sep 3, 2024 · 5 comments

Comments

@roelfdiedericks
Copy link

roelfdiedericks commented Sep 3, 2024

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
Copy link
Author

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
Copy link
Owner

xtaci commented Sep 9, 2024

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
Copy link
Owner

xtaci commented Sep 9, 2024

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

@roelfdiedericks
Copy link
Author

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

@roelfdiedericks
Copy link
Author

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants