UdpClient.BeginReceive gives socket error 10054

[Mutant_Fruit]

I'm using udp at the moment, and every now and again the UdpClient i'm using decides to throw a socket exception with error code 10054. Google tells me this:

Socket error 10054 may be the result of the remote server or some other piece of network equipment forcibly closing or resetting the connection

But this is UDP. There is no connection. What exactly is causing this, and how exactly can i avoid it? My temporary fix is to dispose the existing udpclient and instantiate another one, but that seems a bit stupid. The offending code is here:

        private void EndReceive(IAsyncResult result)
        {
            try
            {
                IPEndPoint e = new IPEndPoint(IPAddress.Any, endpoint.Port);
                byte[] buffer = client.EndReceive(result, ref e);

                // Fire the event to indicate i've received a message
                if (MessageReceived != null)
                    MessageReceived(buffer, e);
            }
            catch
            {
                // ignore
            }
            
            // This is the part which throws an exception randomly
            client.BeginReceive(EndReceive, null);
        }

[chase2534]

This isn't helpful, but why are you using UDP?

Have you gotten similar errors with TCP?

[Mutant_Fruit]

Because that's what the specification calls for, I don't have a choice.

[RaleTheBlade]

It may not mean the connection itself, but the binding of the UdpClient to the local endpoint. If the IPEndPoint is being destroyed by some unknown means, then the binding will be lost and errors like this may happen. Granted UDP is technically a connectionless protocol, but it still needs to bind to an end point using a socket in order to transmit data.

My only guess is its probably network related, I use UDP in some of my apps and have encountered this problem before. My situation was due to losing Wi-Fi signal. Id check to make sure the connection isnt being lost intermittently and that something on the client side isnt forcing the IPEndPoint to become invalid.

This isn't helpful, but why are you using UDP?

Have you gotten similar errors with TCP?

UDP is an excellent choice for sending data across a network that isnt really uber-important. We use it to send data string to a server from client applications, but the thing is, if we lose a data string or two, its not a big deal, another one will come in a second later.

TCP/IP has a lot of overhead involved in programming with it, so its use is best kept to sending important data that is absolutely necessary for one thing or another. I do use it however in sending error reports and in the updater that updates our clients applications.

Also, that's a rather interesting way of doing BeginReceive()/EndReceive(), never seen it done recursively, lol.

[Mutant_Fruit]

It may not mean the connection itself, but the binding of the UdpClient to the local endpoint. If the IPEndPoint is being destroyed by some unknown means, then the binding will be lost and errors like this may happen. Granted UDP is technically a connectionless protocol, but it still needs to bind to an end point using a socket in order to transmit data.

Ah, interesting. I never thought of that, but I'd be a little dubious as to whether that's really the cause or not. I'm binding to 0.0.0.0 port 15000. This shouldn't be affected if a network card goes down. Then again, who knows, windows works in mysterious ways

Also, that's a rather interesting way of doing BeginReceive()/EndReceive(), never seen it done recursively, lol.

I thought that was the way everyone used BeginXXX/EndXXX. It's the pattern I use all the time anyway I wouldn't call it recursive (as stackdepth doesn't increase), it's closer to being serial. As soon as one connection is processed it loops around and waits for the next connection. Whatever you want to call it, it's still a nice way to write it

[RaleTheBlade]

I thought that was the way everyone used BeginXXX/EndXXX. It's the pattern I use all the time anyway I wouldn't call it recursive (as stackdepth doesn't increase), it's closer to being serial. As soon as one connection is processed it loops around and waits for the next connection. Whatever you want to call it, it's still a nice way to write it

I always just used Thread objects, I prefer to have direct control over what takes place during the async operation, hahaha. Plus... when in my C++ Data Structures course a few years back, the way we had to use recursion was nightmarish, lol.

As for your recurring problem, Im not sure what else to say. There may be something weird going on in BeginReceive() thats causing those errors, Ive never had much luck with the async methods that .NET provides. Have you tried putting the UdpClient.Receive() on an actual Thread object and just using a while loop to continually receive and report data? That might help...

It works basically the same way:

UdpClient.Receive(ref IPEndPoint);

You just need to but it on a Thread because it is a blocking call. You might try that just for sh*ts and giggles to see if it works.

[Mutant_Fruit]

I always just used Thread objects, I prefer to have direct control over what takes place during the async operation, hahaha.

But then you lose out on all the benefits of IOCP (io completion ports). If you're using a lot of sockets, you really should use the async methods as opposed to a dedicated thread.

The issue still occurs with a dedicated thread and blocking calls to receive. Maybe my 'solution' is the best way to fix it. The only problem is that even if i instantiate a new listener, how do i know that it won't blow up as soon as i call BeginReceive. That's my problem, i don't know when it's safe and when it's not.

[RaleTheBlade]

That's so weird, I'm assuming you've already made sure that its not being blocked, or that its not being used by some other app. But something is closing that socket... What though? Does it happen on just that machine? Or does is it indifferent to the machine that it runs on? Maybe there's some app on the local machine that's chucking the client off of the IPEndPoint.

Is there an inner exception to the SocketException that's being thrown?