我已经发现默认的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多播的股票交易所数据，所以有时候我的显着跳转（lehman兄弟破产等），但我们假设我每秒不会收到超过20 000个数据包。
如何计算符合我需求的ReceiveBufferSize？
我绝对不同意丢包，但我不会失去性能或可靠性或其他任何东西。
答案 0 :(得分：4)
根据您提供的信息，没有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.
因为，在更糟糕的情况下，每秒大小100字节可以接收高达20k的数据包，如果你将缓冲区大小设置为2 MB（20k * 100字节），你应该能够持续大约一秒钟来自远端的without processing any data。
同样，如果您希望线程在没有读取缓冲区的情况下最长时间是x秒，那么缓冲区大小应为x * 2 MB + (expected size of buffer at such a time)
希望这会有所帮助。
答案 1 :(得分：0)
使用UDP时，增加接收缓冲区大小不会对检测连接问题产生不利影响。
根据需要的时间（无需软件从套接字读取传入数据的时间）来缓冲缓冲区的大小，并根据可用的内存量来确定缓冲区的大小。
您无法控制数据到达的速度。此外，除其他外，垃圾收集器可能会中断您的处理。因此，您也无法可靠地控制处理速度。 因此，您将必须进行测试和/或假设并在必要时进行调整。如果有可用的内存，则可以通过增加接收缓冲区的大小来选择具有更多的安全缓冲区。