UdpClient -- limited buffersize?

Question

I'm having troubles with UdpClient in C#. I am streaming audio over the internet between two clients.

On my microphone, with a sample rate of 16khz, I send UDP packets with audio with 6400 byte per packet. These never get through, except the last packet which is usally around 1200-3400 something since I close the recording. When I lower sample rate to 8khz, I send packets with 3200 byte payload. These always get through for some reason.

So basically anything above 3200 gets botched (havn't tested an exact number but...) why on earth is this? I was thinking perhaps the UdpClient internal buffer is too small or something? Since I stream audio packets gets sent frequently.

RECEIVE:

private void audioReceive(IAsyncResult asyn)
    {
        try
        {
            byte[] temp = audioSock.EndReceive(asyn, ref this.serverEP);
            this.waveProvider.AddSamples(temp, 0, temp.Length);

            this.textbox_display.Text = this.textbox_display.Text + " got bytes: " + temp.Length;
            audioSock.BeginReceive(new AsyncCallback(audioReceive), null);

        }
        catch (Exception ez)
        {
            MessageBox.Show("audioReceive: " + this.textbox_nick.Text + "        " +ez.ToString());
        }

    }

I can't find any obvious fault. (The asyn object to the function is null btw, I do not need to use a stateobject , but that shouldn't be related to this)

I know UDP is not reliable, but considering every single 3200 sized packet get through and no 6400 size smells fishy to me, especially with max size is what, 64kb?

Any ideas?

Answer 1

It is possible for packets exceeding the MTU (which I think is around 1500 bytes) to be discarded. For example, see this. It sounds like you may be running into some form of this. To allow it to work more reliably in different environments, it may be better to maximize the send to 1472 bytes per packet (to allow for packet overhead) and then reassemble them at the receiving end.

Or maybe just use TCP/IP. Even if some loss is acceptable, it can be rather complex to make a "simple" UDP solution work. I work on a product that supports communications for UDP and over TCP/IP, and (educated guess) the UDP implementation involves probably 10 times as much code and has much greater complexity. Of course, in our situation no data loss is acceptable, so that changes it some.