【问题标题】:how to know what ReceiveBufferSize to set?如何知道要设置什么 ReceiveBufferSize?
【发布时间】:2012-03-23 10:09:43
【问题描述】:

我发现默认的 ReceiveBufferSize (8192) 对我不起作用 - 我丢失了数据包 Sockets: sometimes (rarely) packets are lost during receiving

但是 msdn 有关于增加 BufferSize 的警告:

http://msdn.microsoft.com/ru-ru/library/system.net.sockets.socket.receivebuffersize.aspx 较大的缓冲区大小可能会减少空确认(没有数据部分的 TCP 数据包)的数量,但也可能会延迟对连接困难的识别。如果您正在传输大文件,或者您正在使用高带宽、高延迟的连接(例如卫星宽带提供商),请考虑增加缓冲区大小。

我知道我需要每秒接收约 2000 个数据包,每个数据报包含大约 50-100 字节的数据。我正在使用低延迟连接(局域网中的所有内容)。我从 udp 多播接收证券交易所数据,所以有时我的流量显着跳跃(雷曼兄弟破产等),但假设我每秒接收的数据包不会超过 20 000 个。

如何计算适合我需要的 ReceiveBufferSize?

我绝对不同意丢失数据包,但我也不会丢失性能或可靠性或其他任何东西。

【问题讨论】:

  • 备注是关于TCP的。如果您使用 TCP,那么您一开始就不会遇到这个问题。
  • @HansPassant 但如何选择 ReceiveBufferSize?我可以将其设置为 100 MB 并且不关心它吗?
  • 曾经我在接收多播数据时遇到了同样的问题(~4000 个数据包/秒)。我将 ReceiveBufferSize 设置为 256K,问题就消失了。 (为什么是 256K?只是反复试验;))

标签: .net sockets udp


【解决方案1】:

根据您提供的信息,没有ideal figure 可以为您提供 ReceiveBufferSize。
除了你的worse-case incoming data rate,还要看rate at which you process messages,在你被消息轰炸的时候能不能继续这样做。

正如对您问题的评论中提到的,您应该分析您在压力条件下的应用程序,以发现最适合您all the time 的价值。

或者,您可以从 ReceiveBufferSize 的默认值开始,并在您超过预期会丢失数据包的阈值时增加它,当情况正常化时再次降低它。这种方法工作量很大。

已编辑:

平均而言,您处理数据的速度会比收到数据的速度更快。但是,在某些情况下,您可能无法process data at all(例如,您可能必须每收到 100 条消息就同步或串行地写入数据库)。在这种情况下,您必须确保您的缓冲区可以处理来自at that moment.的数据

因为,在最坏的情况下,您每秒最多可以接收 20k 个数据包,每个数据包大小为 100 字节,如果您将缓冲区大小设置为 2 MB(20k * 100 字节),您应该能够持续大约一秒钟without processing any data 来自远端。

同样,如果您希望线程在不从缓冲区读取的情况下运行的最长时间是 x 秒,那么您的缓冲区大小应该是 x * 2 MB + (expected size of buffer at such a time)

希望这会有所帮助。

【讨论】:

  • 那么问题是设置太大的ReceiveBufferSize有多糟糕?也许我可以将其设置为例如 100 MB,然后忘记它,为什么不呢?
  • 我们需要看看 msdn 说 delay the recognition of connection difficulties 是什么意思...我明白你在说什么...
  • @javapowered 那么如果它需要重新发送它,它可能会再发送100 MB?而不是 64kB
【解决方案2】:

当您使用 UDP 时,增加接收缓冲区大小不会对连接问题的检测产生不利影响。

根据您需要多长时间来缓冲传入数据而无需您的软件从套接字读取它们,以及根据可用内存量来确定缓冲区大小。

您无法控制数据到达的速率。此外,垃圾收集器可能会中断您的处理。因此,您也无法可靠地控制处理速率。 因此,您必须进行测试和/或假设,并在必要时进行调整。如果内存可用,您可以通过增加接收缓冲区大小来选择拥有更多安全缓冲区。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-07-03
    • 2021-12-14
    • 2018-07-02
    • 2011-06-11
    • 2017-04-05
    • 2015-01-09
    • 1970-01-01
    • 2015-08-18
    相关资源
    最近更新 更多