Forums Bug Reports closing udp socket clientside-on sockclose+$socker

If I have an udp server "running":and a client "connected" to it:
If I type /sockclose pacuclient, it triggers on sockclose for the server with $sockerr set to 3:

Is this normal?

I have a feeling we've been through this one before. Does this post cover the same issue?

That said, I have not been able to reproduce this issue here. I follow the above steps:

1) /sockudp -k pacuserv 8000
2) /sockudp -kn pacuclient 127.0.0.1 8000 this is a test
3) /sockclose pacuclient

And this event did not trigger:

on *:sockclose:pacuserv:{
echo -s SERVER UDP SOCKCLOSE $sockerr -- $sock(pacuserv).wsmsg
}

You are right! I remember(ed) this thread you linked to but I thought it was a different issue.
In fact it's the same issue. I assume that if you didn't answer that thread at the end it's because you agree with Saturn that it's correct behavior (although he wasn't so sure himself at the end )?

For reference, why this has been bugging me is that, the server use both TCP and UDP, it runs a timer and send udp packet to clients each 45 ms. When clients issue a 'quit', they do so with tcp, but they immediately close the UDP socket, meaning the server will still try to send them packet, until it gets the tcp message.
Of course this is now crystal clear to me, but it wasn't so clear 5 years ago
It's a simple fix for my script, I just need to let the udp socket running on client and ignore further packets until the server get the quit on the tcp socket and remove the client from the list of ip/port to send packet to.

That being said, the thread you linked to still had some valid reports I believe so maybe we can use this thread to deal with them:

Wims left out the core cause of the problem, which is that the server sends a packet to the client. This slightly extended version should be able to reproduce the actual issue:



See my post in the previous thread for possible solutions..

Yeah thanks, I forgot to make it clear in this thread, once I realized it was the same issue, that the server has to send a packet to an IP/PORT combination that is no longer 'valid'.

This is exactly my problem, I was going to implement the solution I mentioned in my previous post here, but I realized it wouldn't matter much, a malicious user could always close the socket himself with /sockclose and ruin the server, but even a non malicious user could be suffering a blue screen or a power outage or anything that would make the socket close client side.

Thanks, I was able to reproduce the issue. It only reproduced when I closed the socket instantly after sending the data. I have tested two fixes: the first checks for WSAECONNRESET errors on UDP sockets and ignores them. The second applies SIO_UDP_CONNRESET to the socket. Both seem to work. Which do you think would be best in this situation? As mentioned here, with UDP the error is not due to a connection reset but to reachability. So either method sounds like it should work correctly.

Ahhhh, finally! Awesome Khaled!

Ah, neat. In that case either fix should suffice indeed. I personally don't see a strong reason for picking one over the other though, and I myself would probably combine both: ignoring WSAECONNRESET for safety reasons, and setting clearing SIO_UDP_CONNRESET for efficiency reasons (but ignoring any failures setting clearing it).