-
-
Notifications
You must be signed in to change notification settings - Fork 191
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
Windows: Connecting to server is delayed if some previous clients do not shutdown by the right way #113
Comments
Can still you reproduce this connection delay if you run a client on a different machine than the one doing the non-cleanup clients? |
Secondly, is your client.c still binding to port 0, eg. random client port number? |
|
This result is very strange. Are the WASECONNRESET errors showing up on the clients or on the server? |
Also, I mean can you reproduce the connection delay with clients running on one machine, and then connect a client from a second machine, to a server running on a third machine? (Sorry to be a pain!) I just want to be 100% sure this is something specific to the server, and not a direct consequence of the socket layer on the clients not having the socket cleaned up. |
I confirm that this issue still happens.
|
OK. I will look into this. Can you please post logs from the clients that connect properly, the client that has the connection delay, the client that fails to connect, and the server -- all with netcode_log_level set to NETCODE_LOG_LEVEL_DEBUG thanks! |
Failed case:
|
Delay case:
|
Right way:
|
Hi, I'm trying to match the client logs with the server logs in the delay case. In the client logs, I see various port numbers. Then I look at the server logs, and I see different port numbers. Are you certain that the server log corresponds to the complete server log in the delay case? Here are the logs I'm working from:
|
@gafferongames I think you are working on the "client log of failure case" with "server log of delay case". They are not on the same case. |
Confirmed. Cross checking port numbers now and it seems to line up. |
I'm going to extend the logs, and try to repro over here |
Does this only happen when the server is running on windows, because I'm on Mac and I cannot repro it even though I have adjusted the client.c to remove the signal handler. |
Yes, it does only on Windows |
The good news is that since it is Windows specific, we can know that the issue is something in the socket receive processing, or the OS support for sockets. The logic is fine -- all logic is shared across all platforms. |
Following this logic, I think I know what it is:
The WSACONNRESET is stopping packets from being received, and it's windows specific... should be able to fix, then you can verify. |
OK, I believe I have a fix checked in now. Let me know how it goes. The issue is windows specific. |
The fix + explanation of what was going on:
|
I think the solution would resolve the issue. However, I have a question. If in the previous frame, client does some |
Yes, the recursion is a bit gross, BUT, there is only one WSAECONNRESET per-packet sent from the server, so I think the recursion won't go on forever, it will be reasonable. Let me know if you see stack issues around the recursion, and if so we can refactor the socket receive function to iterate over recvfrom and ignore WSAECONNRESET until it gets a correct result. |
The only thing I worry about is DDoS spoofing ICMP packets. I would recommend that in production, you block ICMP to your servers. |
Thanks for your advice. I have checked the test case and the issue has gone. |
Closing this out. Thanks for your report! |
Hi,
I run the example
(client.c & server.c)
and found an issue about the cleanup of previous client sessions.I modified
client.c
by commenting the line number 97:signal( SIGINT, interrupt_handler)
to make client cannot cleanup,After that, I built both client & server on Windows, then run the server.
I opened another console to execute client. I repeated opening client and pressing
ctrl + C
to terminate it.After 3 - 4 times of doing like that, the client connected to server after a bit delayed.
It seems that
recvfrom
in (netcode.c:836) emits a lot of WASECONNRESETThe text was updated successfully, but these errors were encountered: