前言
由于TFTP协议过于简单，且没有重传机制；FTP协议很好，但是不能完美的嵌入到已有的代码中，从零开发有一定难度，因此定义了一种基于UDP协议，简单，有确认和重传机制的文件传输协议。
该种协议只有一对Socket套接字，没有控制命令，直接就是文件数据的传输，所以很容易以函数级别嵌入到已有代码中，且对性能的影响非常小，由于协议是在UDP协议的基础上定义的，因此需要有确认机制。通信的两端没有服务端和客户端之分，两端都可以发起。唯一的条件是：两端的UDP通信的Socket已经建立成功，且通信正常。
协议格式
发起端：
总包数（4）、本包序号（4），本包长度（4），本包校验码（2）、本包数据（N）
说明：
文件总包数：文件包总数。
本包序号：包序号，从1开始计。
本包长度：后续“本包数据”字段的长度，如果通讯层包最大32K，该值建议不超过16K。
本包数据校验码：根据CRC计算校验码(只计算”本包数据”字段的内容)。
本包数据：具体需要传输的数据。
接收端：
本包序号（4）、当前状态（2）、重传包序号（4）、保留（2）
说明：
本包序号：当前包的报序号
当前状态：不同的情况对应不同的状态，且数据接收失败，一律丢弃。
- 0x0000：本包数据接收成功，可以接收下一包数据；
- 0x0001：全部数据接收成功；
- 0x0002：本包数据接收失败，长度不符或校验码错，可以重新接收本包数据；
- 0x0003：本包数据接收失败，序号错，需要重新接收“重传包序号（4）”的包；
- 0x0004：本包数据接收失败，单板出现数据存储出错，无法继续接收；
- 0x0005：内存申请失败，无法继续接受；
- 0xFFFF：未知错误，无法继续接收；
- 其他错误码保留，待以后扩展使用
重传包序号：如果需要重传，该字段填写需要重传的包序号
保留：扩展协议使用
扩展
该协议有确认和重传机制，但是没有超时机制，可以添加确认超时机制，保证数据的传输更加稳定!