关于使用c# 编程，构建自动更新程序的问题

在使用c#构建这个自动更新程序，实现一个简单的文件下载的功能，这个功能不难实现，主要出现的问题是断包

1. 问题

   在一开始的时候，为了避免断包和粘包的现象，就是服务端固定传输固定的字节，然后下位机接收固定字节的数据，在PC上直接构建一个TCP服务端和客户端，数据传输是不会有问题的，然而将对应的程序挂载到服务器上（国外），就出现了问题：断包。
   

2. 解决历程

1. 首先，我不太确定是不是将c#程序利用anyexe框架在服务器上运行，出现的问题，所以，我就重新利用了C#的跨平台性，重新写了一个控制台程序（原来的程序只能在PC上运行），试了试，还是不行

2. 接着，判断是不是服务器的问题，就是服务器延时导致的问题，因为服务器是国外的，所以延时是比较长的，测试用的服务器的延时大概是200ms左右，但是我手头又没有国内的服务器，所以我采用了国内服务器透传的方式，来实现，直接在本地搭建一个TCP服务端，然后，通过一个国内的透传软件，将本地的服务端，透传到网络中，然后从对应的透传端口传输。通过试验，是不会出现断包的问题的，所以可以确定的是，断包的问题就是在于由于网络延时而导致的断包现象

3. 问题的根源

1. 通过好多次的测试，比如加校验，加每次传输一次（1024字节）就再次请求一次，第一个没用，第二个有点用，但是会出现一个问题，那就是传输的文件越大，耗时就越长，因为服务器是有200ms左右的延时的。

2. 所以为了避免出现延时的问题，就不能采用这个一应一答的方式。必须要改变。思考再三，在一开始的时候，就不能用以传输的包数作为判断，包数：文件的大小除以每次传输的字节数1024字节，但是在使用socket传输的固定1024字节的时候，客户端不一定是收到一次就收到1024字节数据，它可能分开收这个1024字节的所以，这个是出现问题的根本原因，所以要改变传输的文件结束的判断方式

4. 解决办法

1. 通过字节数进行判断，单文件是否传输完毕，这个办法果然很好用，通过客户端的接收判断，果然，有时候会接收到非1024字节的数据包（不包括最后一个包）
            length = my_tcpStream.Read(receive, 0, data_length);                     //获取更新文件数据
                  if (length != 1024) {
                       MessageBox.Show("总包数："+ pack_count+"包数："+pack_current);          
                       MessageBox.Show("接收到字节："+length);
                       }               

5. 总结

1. 有时候，就是差那么点，要尽可能的多考虑其他因素影响