情况：我正在使用msdn中记录的HttpWebRequest.BeginGetResponse。我有一个计时器每十秒发送一次请求。我测试时收到了xml结构的信息。
结果：在客户所在地并且运行该工具我收到了不完整的（因此不可解决的）xmls（每个大约4KB）。我可以在浏览器中检查并完全看到它（显然是通过浏览器的同步请求？！）。我使用了有关内容长度的标题信息来调整接收缓冲区的大小。
是什么引起的？我不知道。数据相当小。我仍然使用developer fusion中描述的ThreadPool.RegisterWaitForSingleObject方法来定义超时，我也为超时选择了10秒。也许这不是一个聪明的决定，它可能应该小于计时器间隔。问题是，我无法在这些条件下再次测试它。它是在一个生产现场，我没有洞察网络设置。在家里的同时，这些房子也很好。
我在该领域不是很有经验，但是当计时器在完全接收到响应流之前触发新请求时会发生什么，例如，超时时间是否等于定时器间隔？还有什么其他暗示可以成为这里的瓶颈吗？
答案 0 :(得分：1)
解决方案很简单。只有在完成响应处理后才启动计时器。
答案 1 :(得分：1)
您是如何接收数据的？你是通过流阅读数据吗？你使用返回的contentize作为Stream.Read的输入参数吗？ Stream.Read的一个功能并不完全明显，它不能保证返回您请求的数据量。 当您调用以下功能时
public abstract int Read(byte[] buffer, int offset, int count )
它将返回实际读取的数据量。因此，您可能要求它读取1000并返回400，然后仍有600个字节需要读取。 这意味着你必须继续调用Read直到它返回0（这意味着流中没有更多的数据）。
我还要说你不应该使用内容长度标题信息来调整缓冲区的大小。相反，您应该创建一个动态大小的缓冲区（例如，通过使用MemoryStream对象）并从响应流中读取，直到它返回0.至少，我就是这样做的。然后，如果服务器更改实现，那么您的解决方案将继续工作，因此它不再发送该响应头。 或者甚至更好，因为您正在加载XML，创建一个XmlDocument，并要求它直接从Http响应流加载。
答案 2 :(得分：0)
如果它是您要连接的其他服务器，则服务器的响应也可以“分块”。我在某处看到httpwebrequest有一个错误，在chunked服务器上，它不会返回完整的文件
如果是这种情况，请确保服务器没有为http流量启用“分块模式”。
或者，如果这超出您的范围，请使用普通套接字自行执行请求，发送http请求，然后获取完整结果。
在进入这条路线之前，首先要确保这个分块模式是这里的问题
[R