How do I know if UdpClient has been closed/disposed?
Asked Answered
D

3

5

I am receiving data from UdpClient via the usual async callback:

private void OnUdpData(IAsyncResult result)
{
    byte[] data = _udpReceive.EndReceive(result, ref _receiveEndPoint);

    //Snip doing stuff with data

    _udpReceive.BeginReceive(OnUdpData, null);
}

When I Close() the UdpClient in the main thread, the callback fires as I would expect, but at this point _udpReceive is already disposed and I get an ObjectDisposedException when I try and call EndReceive(). I was expecting to just get an empty buffer.

What is the correct way to handle this? Is there some member of UdpClient I can check before trying to use it, or it the only way to wrap it all in a try{} and catch the ObjectDisposedException? That seems pretty nasty for a normal close.

Diphthongize answered 16/2, 2012 at 11:23 Comment(0)
A
4

This is entirely by design. You did something exceptional, you closed the socket even though you expected data to be received. So you'll get an exception. The .NET framework always makes sure that asynchronous calls are completed and that the abort reason is signaled in the callback when you call EndXxx(). Good idea, that lets you clean up any state associated with the callback.

You can make it non-exceptional by waiting until the transfer is complete, stop calling BeginReceive() and then close the socket. But that isn't always practical or sometimes you really want to terminate early. Not a problem, simply catch the ObjectDisposedException and get out. Of course, do consider what happens to the app on the other end of the wire. Anything it sends afterward is going to fall in the bit-bucket with no way for it to find out.

Alisander answered 16/2, 2012 at 12:31 Comment(0)
D
5

You can do this to check if its disposed. Client is set to null when the UdpClient is disposed.

private void OnUdpData(IAsyncResult result)
{
    if (_udpReceive.Client == null)
        return;
    byte[] data = _udpReceive.EndReceive(result, ref _receiveEndPoint);

    //Snip doing stuff with data

    if (_udpReceive.Client == null)
        return;
    _udpReceive.BeginReceive(OnUdpData, null);
}

Although because you are closing it in a separate thread you may end up with a race condition. It would be best to just catch ObjectDisposedException and SocketException.

private void OnUdpData(IAsyncResult result)
{
    try
    {
        byte[] data = _udpReceive.EndReceive(result, ref _receiveEndPoint);

        //Snip doing stuff with data

        _udpReceive.BeginReceive(OnUdpData, null);
    }
    catch (Exception e)
    {
        //You may also get a SocketException if you close it in a separate thread.
        if (e is ObjectDisposedException || e is SocketException)
        {
            //Log it as a trace here
            return;
        }
        //Wasn't an exception we were looking for so rethrow it.
        throw;
    }
}
Disaffection answered 16/2, 2012 at 11:42 Comment(2)
Does the callback relieve one of the responsibility to call EndReceive? My impression was that except for some types of IAsyncResult which do not tie up resources (e.g. the return value of Control.BeginInvoke) one is supposed to always call EndXX after every BeginXX. Note that the exception one catches is not a sign that the EndReceive operation failed, but is rather the consequence of "successful" EndReceive call relaying the exception which resulted in the receive attempt.Thorton
Isn't EndX only called to get the data from the BeginX? Well either way in this case that return is fine. The EndReceive will check the same thing and throw a disposed exception anyways.Disaffection
A
4

This is entirely by design. You did something exceptional, you closed the socket even though you expected data to be received. So you'll get an exception. The .NET framework always makes sure that asynchronous calls are completed and that the abort reason is signaled in the callback when you call EndXxx(). Good idea, that lets you clean up any state associated with the callback.

You can make it non-exceptional by waiting until the transfer is complete, stop calling BeginReceive() and then close the socket. But that isn't always practical or sometimes you really want to terminate early. Not a problem, simply catch the ObjectDisposedException and get out. Of course, do consider what happens to the app on the other end of the wire. Anything it sends afterward is going to fall in the bit-bucket with no way for it to find out.

Alisander answered 16/2, 2012 at 12:31 Comment(0)
M
0

Based on your question, it sounds like you would like to avoid the Exception being thrown when forcing the client to close. I'm going to take some guesses about your code and try to provide a solution:

Since you have a method named "OnUdpData" I'm assuming you have a wrapper class around the UDPClient. In that wrapper class, you could do something like this: Set a flag that indicates that you are closing the client and should no longer use the client immediately before attempting to close the client. This avoids the race condition caused by checking _udpReceive.Client == null before calling EndReceive() since the main thread could close the client after the Client conditional check.

    private bool _finishedListening = false;

    public void StopListener()
    {
        _finishedListening = true;
        _udpReceive.Close();
    }

    private void OnUdpData(IAsyncResult result)
    {
      if (_finishedListening == true)
        return;
      byte[] data = _udpReceive.EndReceive(result, ref _receiveEndPoint);
      //Snip doing stuff with data
      _udpReceive.BeginReceive(OnUdpData, null);
    }
Minda answered 30/6, 2020 at 17:23 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.