5

我在 C# 中遇到了 UdpClient 的问题。我正在两个客户端之间通过 Internet 流式传输音频。

在我的麦克风上，采样率为 16khz，我发送带有音频的 UDP 数据包，每个数据包 6400 字节。这些永远不会通过，除了最后一个数据包，自从我关闭录音以来，它通常在 1200-3400 左右。当我将采样率降低到 8khz 时，我会发送 3200 字节有效负载的数据包。由于某种原因，这些总是通过。

所以基本上任何高于 3200 的东西都会被搞砸（还没有测试过确切的数字，但是......）这到底是为什么？我在想 UdpClient 内部缓冲区可能太小还是什么？由于我经常发送流式音频数据包。

收到：

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());
        }

    }

我找不到任何明显的错误。（函数的 asyn 对象是 null 顺便说一句，我不需要使用 stateobject ，但这不应该与此相关）

我知道 UDP 不可靠，但考虑到每个 3200 大小的数据包都通过并且没有 6400 大小的数据包对我来说很可疑，尤其是最大大小是什么，64kb？

有任何想法吗？

4

3 回答 3

2

超过 MTU（我认为大约 1500 字节）的数据包可能会被丢弃。例如，看到这个。听起来您可能会遇到这种情况。为了让它在不同的环境中更可靠地工作，最好将每个数据包的发送最大化为 1472 字节（以允许数据包开销），然后在接收端重新组合它们。

或者也许只是使用 TCP/IP。即使有些损失是可以接受的，但要使“简单”的 UDP 解决方案工作起来可能相当复杂。我正在开发一个支持 UDP 和 TCP/IP 通信的产品，并且（有根据的猜测）UDP 实现可能涉及 10 倍的代码并且具有更大的复杂性。当然，在我们的情况下，没有数据丢失是可以接受的，所以它会有所改变。

于 2010-12-16T00:13:32.940 回答
0

使用 IPv4 可以保证 576 字节（UDP 有效负载为 548），但对于大多数用户来说，至少应该保持在 1472 字节（1444 UDP）以下。

您可以使用此处描述的 ping 测试 MTU 大小的工作原理，

http://help.expedient.net/broadband/mtu_ping_test.shtml

libjingle使用 1280 字节的安全默认值（1252 UDP/IPv4、1232 UDP/IPv6），它与 IPv6 的保证最小值相匹配，

http://code.google.com/p/libjingle/source/browse/branches/nextsnap/talk/session/tunnel/pseudotcpchannel.cc?spec=svn17&r=13

于 2010-12-16T03:50:32.963 回答
0

自 2014 年以来，此链接可能是此问题的最佳答案：

UdpClient 类 .NET 参考源。

private const int MaxUDPSize = 0x10000;  
...
private byte[] m_Buffer = new byte[MaxUDPSize];
于 2015-03-29T07:57:47.150 回答