Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Cause of high UDP package loss on localhost?

Tags:

c#

udp

udpclient

In my WPF 4.0 application, I have a UDP listener implemented as shown below. On my Windows 7 PC, I'm running both server and client on localhost.

Each received datagram is a scanline of a larger bitmap, so after all scanlines have been received the bitmap is shown on the UI thread. This seems to work. However, occasionally some 1-50% scanlines are missing. I would expect this on a weak network connection, but not when run locally.

What may cause UDP package loss with the following piece of code?

IPEndPoint endPoint = new IPEndPoint(IPAddress.Any, PORT);
udpClient = new UdpClient(endPoint);
udpClient.Client.ReceiveBufferSize = 65535; // I've tried many different sizes...

var status = new UdpStatus()
{
    u = udpClient,
    e = endPoint
};

udpClient.BeginReceive(new AsyncCallback(UdpCallback), status);

private void UdpCallback(IAsyncResult ar)
{
    IPEndPoint endPoint = ((UdpStatus)(ar.AsyncState)).e;
    UdpClient client = ((UdpStatus)(ar.AsyncState)).u;

    byte[] datagram = client.EndReceive(ar, ref endPoint);

    // Immediately begin listening for next packet so as to not miss any.
    client.BeginReceive(new AsyncCallback(UdpCallback), ar.AsyncState);

    lock (bufferLock)
    {
        // Fast processing of datagram.
        // This merely involves copying the datagram (scanline) into a larger buffer.
        //
        // WHEN READY:
        // Here I can see that scanlines are missing in my larger buffer.
    }
}

If I put a System.Diagnostics.Debug.WriteLine in my callback, the package loss increases dramatically. It seems that a small millisecond delay inside this callback causes problems. Still, the same problem is seen in my release build.

UPDATE

The error becomes more frequent when I stress the UI a bit. Is the UdpClient instance executed on the main thread?

like image 681
l33t Avatar asked Aug 28 '13 09:08

l33t


1 Answers

To avoid the thread block issue, try this approach that uses the newer IO Completion port receive method:

private void OnReceive(object sender, SocketAsyncEventArgs e)
{
TOP:
    if (e != null)
    {
        int length = e.BytesTransferred;
        if (length > 0)
        {
            FireBytesReceivedFrom(Datagram, length, (IPEndPoint)e.RemoteEndPoint);
        }
        e.Dispose(); // could possibly reuse the args?
    }
    Socket s = Socket;
    if (s != null && RemoteEndPoint != null)
    {
        e = new SocketAsyncEventArgs();
        try
        {
            e.RemoteEndPoint = RemoteEndPoint;
            e.SetBuffer(Datagram, 0, Datagram.Length); // don't allocate a new buffer every time
            e.Completed += OnReceive;
            // this uses the fast IO completion port stuff made available in .NET 3.5; it's supposedly better than the socket selector or the old Begin/End methods
            if (!s.ReceiveFromAsync(e)) // returns synchronously if data is already there
                goto TOP; // using GOTO to avoid overflowing the stack
        }
        catch (ObjectDisposedException)
        {
            // this is expected after a disconnect
            e.Dispose();
            Logger.Info("UDP Client Receive was disconnected.");
        }
        catch (Exception ex)
        {
            Logger.Error("Unexpected UDP Client Receive disconnect.", ex);
        }
    }
}
like image 174
Brannon Avatar answered Sep 22 '22 15:09

Brannon