tftp客户端设计小结

tftp协议全称是Trivial File Transfer Protocol，小文件传输协议。这个协议是基于UDP的，仅支持文件的上传和下载。

协议规定的发送报文的规则如下：

1.A向B请求读B中的文件，不带扩展选项

A发送一个RRQ请求给B，这个请求是发送到B的69端口。

B同意，直接开始发送DATA报文，数据包会带有一个block number，作为双方识别数据报文的标识。

A收到数据包之后，发送一个ACK报文给B表示自己已经收到数据报文，这个ACK报文也带有一个block number，这个值就是A收到的数据包中包含的block number。

B不停发DATA报文给A，A不停回复ACK报文。由于DATA报文中发送的数据固定大小为512字节，所以当B发送给A一个数据区小于512字节的DATA报文的时候，A就知道传输结束了，A收到这个报文，回复ACK，结束传输。

2.A向B写文件到B中，不带扩展选项

A发送一个WRQ请求给B，同样发送到B的69端口。

B同意，回复ACK报文给A，这个ACK报文的block number是0，用于向A表示准备好接受，可以发送报文了。

A开始发送DATA报文给B，B收到DATA报文回复ACK报文给A，规则同1中，直到结束。

3.超时的情况

A和B在传递报文的过程中，如果超过一定的时间没有收到报文，会判定为超时，如果在1的条件下，B发送的DATA报文（比如blknumber为10）A一直没有收到，A会发送上一个发送过的ACK报文（blknumber是9的那个）给B，B收到之后就会再发送blknumber为10 的DATA报文给A。

4.扩展选项

tftp中的扩展选项可以有设定DATA报文中数据区的大小，即设定block size，设定超时的时间timeout，设定在请求的时候带上文件大小等。

默认情况下block size为512，timeout为2，不请求文件大小。

扩展选项需要在发送RRQ/WRQ报文的时候添加，这时候，回复报文的过程会有不一样，比如A发送一个带option（扩展选项）的读请求报文给B，B会回复一个OACK报文给A用来确认A的option请求B同意了，然后A会回复一个blknumber是0 的ACK报文给B，表示准备好接受数据，B再开始发送DATA报文。

或者A发WRQ给B——B回复OACK——A开始写，发送DATA报文。

tftp代码实现

参考http://blog.csdn.net/tjssehaige/article/details/8546817

编码反思

1.本身不涉及算法，按照tftp协议的流程来就行，但是值得注意的是在代码中发送报文要严格按照tftp各种报文的结构，比如上面的代码编写中发送代码的方式就是为了严格一层一层封装。

2.判断流程结束的时候，用的是接受到的DATA报文数据区大小小于512（或者设定的blksize），但是如果恰好最后一个数据块也是512怎么办，服务器端自己发送完数据断开了，但是客户端仍旧以为没有发送完，这个时候一直接受不到下一个报文，多次超时后会判定为传输失败，但其实已经完整的接受到文件了。