转自：http://www.cnblogs.com/ITBread/p/3900254.html

 

最近在做一个udp升级程序，因文件有点大，需要将程序分成多个包发送，每次发送一个包，收到回复后发送下一个包，直到完成，这样就控制为顺序发送，保证了完整性，简单定义一个协议，每个包，包含包编号，当前数据长度等信息

包头	命令	子命令	总包数	包编号	总长度	当前包长度	校验信息	数据
6byte	1	1	1	1	4	4	2	0-1024

命令：290

子命令：发送开始为 1   发送数据为2  发送成功为3（接收端发送给发送端）  发送失败为4

总包数： 文件分成多少个包

包编号：当前发送的是第几包（索引从0开始）

总长度：文件长度

当前包长度：当前包的数据长度（《=1024）每次发送1024，最后一包可能少于1024

校验信息：用计算是否丢包用，可以用crc算法 ，这里为了简单设置为0

升级程序流程如下：

1、发送开始命令（发送端--》接收端）

2、传输数据（发送端收到接收端的第一个回复后，然后发送第一个数据包，收到第2个回复，然后发送的第3个包，如此循环，直到发送完成）

3、传输数据完成（接收端，收到所有包后，发送成功命令给发送端）

以上是处理思路，写好代码之后，测试ok，因设备太多 上1000台，一个一个人工处理，太麻烦，想批量升级，修改代码后，可以使用，一次最多5台，多了就会出现部分设备发送到一部分时就不成功。仔细检查处理流程，并没有发现任何错误，最后请同事帮忙看代码，分析也没有发现错误，抓包（Wireshark）分析后，有收到回复包，也有发送数据，但就是中断了，仔细分析后，猜测是接收缓冲区小（默认8192字节），设置接收缓冲区为32k字节后，再试，可以一次升级20多台。

查找相关资料后，是由于udp接收数据大于缓冲区时就会把数据丢掉。

分析原因：一个数据包1k多，5台接近8192，这就是为什么5台时，很顺利。

同理设置接收缓冲区为32k后，就可以升级20多了。