我们有一个TCP流协议,我们通过大小为数据有效负载添加前缀.因此,数据可以在收到时正确解码.很标准的东西.
这对成千上万的人来说很好.不幸的是,我们至少有4个客户端存在连接问题的案例,都在偏远国家.俄罗斯的一位客户已经能够帮助我们进行大量测试并缩小问题范围.如果我们发送一个强制前缀大小为0的数据包,则整个数据包将通过.如果数据包数据以数据包开始1c将无法通过.
我有两个并排的Wireshark从他的电脑中捕获,显示:
Working
-------
Russia -> Toronto [SYN]
Toronto -> Russia [SYN, ACK]
Russia -> Toronto [ACK]
Russia -> Toronto [PSH,ACK] <- data is sent here
00000000000000001c0000000000000000000000000000000000000000000000
Toronto -> Rusion [PSH,ACK] <- server in toronto got the data, sent a reply!
Not-Working
--------
Russia -> Toronto [SYN]
Toronto -> Russia [SYN, ACK]
Russia -> Toronto [ACK]
Russia -> Toronto [PSH,ACK] <- data is sent here
1c000000000000001c0000000000000000000000000000000000000000000000
Russia -> Toronto [PSH,ACK] <- TCP Retransmission
Russia -> Toronto [PSH,ACK] …我试图从公共URL下载一个大文件.它起初似乎运行良好,但1/10计算机似乎超时.我最初的尝试是使用,WebClient.DownloadFileAsync但因为它永远不会完成我回到使用WebRequest.Create并直接读取响应流.
我使用的第一个版本WebRequest.Create发现了同样的问题WebClient.DownloadFileAsync.操作超时,文件未完成.
如果下载超时,我的下一个版本会添加重试.这是奇怪的.下载最终完成1次重试以完成最后7092字节.因此,文件的下载大小完全相同但文件已损坏且与源文件不同.现在我希望腐败在最后7092字节,但事实并非如此.
使用BeyondCompare我发现损坏的文件中缺少2个字节块,总计缺少7092个字节!在下载超时并重新启动之前,这个丢失的字节位于1CA49FF0和1E31F380之前.
这可能会发生什么？有关如何进一步追踪此问题的任何提示？
这是有问题的代码.
public void DownloadFile(string sourceUri, string destinationPath)
{
//roughly based on: http://stackoverflow.com/questions/2269607/how-to-programmatically-download-a-large-file-in-c-sharp
//not using WebClient.DownloadFileAsync as it seems to stall out on large files rarely for unknown reasons.
using (var fileStream = File.Open(destinationPath, FileMode.Create, FileAccess.Write, FileShare.Read))
{
long totalBytesToReceive = 0;
long totalBytesReceived = 0;
int attemptCount = 0;
bool isFinished = false;
while (!isFinished)
{
attemptCount += 1;
if (attemptCount > 10) …