NetworkStream.读取延迟.Net

发布于 2024-08-16 07:15:25 字数 550 浏览 3 评论 0原文

我有一个继承自 TcpClient 的类。在该课程中,我有一种处理响应的方法。在我调用的方法中,我使用 MyBase.GetStream 获取 NetworkStream 并对其调用 Read 。

这工作得很好,除了第一次调用读取块的时间太长。太长是指套接字已收到大量数据,但在达到某个任意限制之前不会读取数据。我可以看到它使用数据包嗅探器 WireShark 收到了大量数据。

我已将接收缓冲区设置为少量,并且非常少量(例如几个字节)无济于事。我对传递给 read 方法的缓冲区字节数组做了同样的事情,但它仍然延迟。

或者换句话说。我下载了600k。下载需要 5 秒(与服务器的连接速度略高于 100k/秒,这是有道理的)。初始 Read 调用需要 2-3 秒,并告诉我只有 256 个字节可用(256 是接收缓冲区和我读入的数组的大小)。然后神奇的是,其他几十万字节可以在 256 字节块中读取,每个块只需几个进程滴答。使用数据包嗅探器,我知道在最初的 2-3 秒内,套接字收到的数据远不止 256 个字节。我的连接速度不是 0.25k/秒 3 秒,然后是 400k/秒 2 秒。

当字节传入时,如何从套接字获取字节?

I have a class that inherits from TcpClient. In that class I have a method to process responses. In that method I call I get the NetworkStream with MyBase.GetStream and call Read on it.

This works fine, excpet the first call to read blocks too long. And by too long I mean that the socket has recieved plenty of data, but won't read it until some arbitrary limit is reached. I can see that it has recieved plenty of data using the packet sniffer WireShark.

I have set the recieve buffer to small amounts, and very small amounts (like just a few bytes) to no avail. I have done the same with the buffer byte array I pass to the read method, and it still delays.

Or to put it another way. I am download 600k. The download takes 5 seconds (at a little over 100k/second connection to the server which makes sense). The initial Read call takes 2-3 seconds and tells me only 256 bytes are availble (256 is the Recieve buffer and the size of the array I read in to). Then magically, the other few hundred thousand bytes can be read in 256 byte chunks in only a few process ticks each. Using a packet sniffer, I know that during those initial 2-3 seconds, the socket has recieved much more than just 256 bytes. My connection wasn't .25k/second for 3 seconds and then 400k for 2 seconds.

How do I get the bytes from a socket as they come in?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

左岸枫 2024-08-23 07:15:25

我在编写开源 C# 网络库 时遇到了类似的问题。尝试设置:

tcpClient.NoDelay = true;
tcpClient.Client.NoDelay = true;

这会禁用默认运行的 nagle 算法。当发送和接收非常少量的数据时,这会故意导致各种随机延迟。

I had a similar issue when writing an open source C# network library. Try setting:

tcpClient.NoDelay = true;
tcpClient.Client.NoDelay = true;

This disables the nagle algorithm operating by default. This causes all sorts of random delays, deliberately, when sending and receiving very small amounts of data.

心房敞 2024-08-23 07:15:25

我以前也遇到过几次这种情况,这似乎与检查机器的 Internet Explorer 设置(代理设置/LAN 设置等)有关,这导致了 2-3 秒的延迟。

System.Net 命名空间内的类(即 WebClient、HttpWebRequest)似乎会在第一个请求时自动执行此操作。

您可以尝试关闭或更改 IE 的代理设置/LAN 设置,特别是自动设置检测选项,它可能会有所帮助。

如果这没有帮助,请查看这篇文章: 首次使用 HttpWebRequest.GetRequestStream 时出现神秘延迟。这不完全是 TcpClient,但我认为这是同样的问题。

希望这有帮助。

I've encountered this a few times before too, and it seems to have to do with checking up on the machine's Internet Explorer settings (proxy settings/LAN settings etc etc) which caused the 2-3 seconds delay.

Classes inside the System.Net namespace (i.e. WebClient, HttpWebRequest) seems to do this automatically on the first request.

You can try turning off or changing IE's proxy settings/LAN settings particularly the automatic settings detection option, it may help.

If that doesn't help, take a look at this article: Mysterious delay on first use of HttpWebRequest.GetRequestStream. It's not exactly the TcpClient but I think it's the same problem.

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文