异步TCP通信-缓冲区大小问题 [英] Asynchronous TCP Communications - Buffer Size Question

问题描述

大家好

我正在忙于异步TCP服务器和客户端.

我开始理解这种设计模式背后的想法和概念.而且感觉很舒服.

我想知道的是，当我为客户端创建读取缓冲区时，该缓冲区有多大? 256个字节? 512字节? 1024 * 10个字节?

为了对此进行压力测试，我有多个客户端以无限循环的方式向服务器发送纯文本消息，即每分钟大约1GIG的流量.然后，服务器将其回显到所有其他已连接的客户端.

我已经看到一些奇怪的事情发生，例如数据包甚至数据包中的单个字符都丢失了，我认为这与缓冲区有关，因为当我不通过无限循环发送消息时，它的工作正常.

任何想法和想法或指针都非常受欢迎:-)

谢谢

Hey guys

I''m busy working on an asynchronous TCP server & client.

I''m starting to understand the ideas and concepts behind this design pattern. And feel pretty comfortable with it.

What I''d like to know is when I create a read buffer for a client, how big do I make it? 256 bytes? 512 bytes? 1024 * 10 bytes?

To stress test this I have multiple clients that send plain text messages to the server in in infinite loop, more or less 1GIG of traffic per minute. The server then just echos it to all the other connected clients.

I''ve seen some weird things happen like packets or even single characters in the packets going missing, I think it has something to do with the buffers cause its works fine when im not sending messages via an infinite loop.

Any thoughts and ideas or pointers are more than welcome :-)

Thanks

推荐答案

缓冲区大小并不是问题，它可以确保您读取所有传入的数据.换句话说，当您在流上调用read()并且它返回整个缓冲区大小作为读取的字节时，您将需要处理该大小.如果不这样做，则可能会丢失一些数据.

附带说明一下，TCP保证传送(除非发生灾难性故障)，因此，如果您获取损坏的数据，则很有可能来自您的应用程序.

Buffer size isn''t the issue so much as ensuring you read all incoming data. In otherwords, when you call read() on the stream and it returns the entire buffer size as the bytes read, you will want to handle that. If you don''t, you risk losing some data.

On a side note, TCP guarantees delivery (barring catastrophic failure), so if you''re getting corrupted data, it''s most likely from your application.

只需检查一下，您在使用TCP吗?如果是这样，则保证所有消息(对于给定的保证值)都是完整的.

如果您期望高容量，那么首先要做的就是确保接收器将数据从入站队列PDQ中取出，并将其放到您在不同线程上管理的调用堆栈中.

通常的错误是直接从TCP/IP管道处理数据并将世界扩展到阳光普照的地方.

Just to check, you are using TCP? If so all messages are guaranteed [for a given value of guaranteed] to be complete.

If you are expecting high volume then the first thing to do is make sure your receiver takes the data off the inbound queue PDQ and puts it onto a call stack that you manage on a different thread.

A regular mistake is to process data directly from the TCP/IP pipe and expext the world to be sunny.

这篇关于异步TCP通信-缓冲区大小问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！