Hello all, it's a weird thread title, I agree, but I'm having some troubles with UDP and the socket telling me that the remote connection has been reset. Here's what I'm doing: Server: Create socket (dgram, udp) and bind it on 0.0.0.0, port xxxx Start loop and do a blocking "receivefrom(bytes, endpoint)". Client: Create socket and bind it on 0.0.0.0, port yyyy Set server address to 127.0.0.1, port xxxx Send datagrams to 127.0.0.1, port xxxx When the server receives something and it's valid, it sends a short ACK packet back to the client (127.0.0.1, port yyyy), which then knows that the packet was received. Everything works fine, until I start up another client (port zzzz). They communicate just fine, but when I kill one of the clients (via CTRL-C), the socket object on the server creates error 10054 (connection reset on remote). It is still able to receive data from the other client that is still running, but it also keeps generating the error 10054. Example: loop: recvfrom() returns data from client recvfrom() return error 10054 recvfrom() returns data from client recvfrom() return error 10054 recvfrom() returns data from client recvfrom() return error 10054 and so on ... This does not seem to make any sense to me. Shouldn't the recvfrom() just sit and wait until it receives data from whatever source? It should not matter if a client was killed, sincethat one will simply stop sending data, correct? The server socket seems to remember that it received some data at some point from someone and keeps telling me that it lost the connection to that client, but UDP is connectionless, isn't it? This drives me crazy and I would be happy if anyone could shed any light on this matter. Thanks in advance, Henning Thoele

The socket is actually receiving an ICMP packet back to tell it the other end's dead - stop sending from the server to the dead client and the error goes away.

If you've implemented a reliable UDP method (resend / ack) you need to ensure that you also drop all outgoing ack packets queued for that client, and also flush the resend queue for that client.

O.O

You're right!
One thing the server does is sending the packets it receives from one client back to the other clients. After removing this, the messages go away.

Is there a way to find out where the ICMP packet comes from? I'm asking this, because the IPEndPoint structure returned by ReceiveFrom() doesn't contain a valid IP address/port. (By the way, I'm using the C# implementation of Winsock, which is, as far as I know, simply a layer on top of the Win32 Winsock functions)

Eh, nevermind, I know which client is dead, since I'm not receiving any ACK packets for those messages I'm sending :-)