UdpClient——有限的缓冲区大小? [英] UdpClient -- limited buffersize?

查看:49
本文介绍了UdpClient——有限的缓冲区大小?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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

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

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.

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

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.

接收:

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 ,但这不应该与此相关)

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)

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

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?

有什么想法吗?

推荐答案

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

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.

或者也许只是使用 TCP/IP.即使某些损失是可以接受的,使简单"的 UDP 解决方案起作用也可能相当复杂.我从事支持 UDP 和 TCP/IP 通信的产品,并且(有根据的猜测)UDP 实现涉及的代码可能是其 10 倍,并且具有更大的复杂性.当然,在我们的情况下,没有数据丢失是可以接受的,因此对其进行了一些更改.

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.

这篇关于UdpClient——有限的缓冲区大小?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆