TFTP协议的SDL设计与C实现整理文档格式.docx

TFTP协议的SDL设计与C实现整理文档格式.docx

《TFTP协议的SDL设计与C实现整理文档格式.docx》由会员分享，可在线阅读，更多相关《TFTP协议的SDL设计与C实现整理文档格式.docx（17页珍藏版）》请在冰点文库上搜索。

2）文件传输

TFTP没有用户权限管理，用户不需要发送用户名或口令，只有文件的读或写权，权限许可时，文件才能被传输。

无证实方式。

传输8位数据.

●通道性质：

TFTP客户机和服务器之间的通信是基于UDP/IP协议。

●工作模式：

TFTP不支持交互，也没有命令集，因此不允许用户列出目录的内容或者与服务器进行交互，判断可用的文件名称.TFTP使用客户服务器模式，一般支持两种传输模式：

一是,netascii,即8比特ASCII码;

二是,Octet，即8比特字节.可对文件进行读或写。

二协议功能分析

●传输开始于客户端发送一个文件读（下载）或写（上载）请求

●服务器使用UDP69号端口接收读/写请求，并建立一个新的连接

●支持两种数据传输模式netascii和octet

●每次传送的数据PDU包含定长512字节数据，不足512字节视为文件的最后一包数据，表示传输结束。

●每块数据按序编号，从1开始

●双方都提供确认机制,都提供超时重传

●差错包导致传输终止（除源端口错误外），此包无需确认,无需重传

●无校验机制

A.SDL功能图

B.进程图

三协议结构设计

分类

●接收实体和发送实体

分层

●客户端和服务端

●用户

●通道接口子层

四协议机制设计

●流控机制：

每个数据包包括一个数据块，客户只有等到服务器的一个确认包以后才会发送下一个数据包，如果一个数据包小于512字节，则表示传输结束。

●转发、确认机制：

发送者每次只能发送一个包，以使确认机制可以保证以前发送的包都已经收到.在一个传输过程中,通信双方既是发送者又是接收者，一方传输数据接收确认，另一方发送确认接收数据.

●错误机制:

有许多错误可以导致连接终止，错误用发送错误包的形式通知对方,此包不会被确认，也不需要重传.如果错误包丢失，则使用超时机制检测。

有以下8种错误：

●超时机制:

如果一个包（数据包或确认包）在传输过程中丢失，定时器将会超时，并重发上一个包

五协议元素设计

1）服务原语和服务原语时序

初始连接时需要发出WRQ（请求写入）或RRQ（请求读取），收到一个确定应答,一个确定可以写出的包或应该读取的第一块数据，通常确认包包括要确认的包的包号，每个数据包都与一个块号相对应，块号从1开始而且是连续的.因此对于写入请求的确定是一个比较特殊的情况，因此它的包号是0。

如果收到的包是一个错误的包，则这个请求被拒绝.

需要四条服务原语：

●读写请求：

WRQ、RRQ（filename文件名，mode文件格式）

●指示：

Data（seqno为序号，data为文件内容）

●响应:

ReadFile_RESP（filename为文件名，mode为文件格式）

●证实：

ACK（seqno为序号+1）

2）五种协议数据单元PDU

A.数据格式

●读文件请求包:

Readrequest,简写为RRQ，客户端发送RRQ报文，服务器响应DATA报文

●写文件请求包:

Writerequest，简写为WRQ，存储文件请求，服务器响应块号为0的ACK报文,客户端收到确认后，发送块号为1的第一个数据包

●文件数据包:

DATA,发送数据包,数据用DATA报文发送后,等待ACK报文，如果发送端在超时前收到ACK报文就发送下一个数据块，否则重传未被确认的数据包文

●确认包：

Acknowledgement，简写为ACK,数据确认报文

●差错包：

ERROR，出错报文

B.PDU交换时序

a）正常终止

一个包含0~511字节数据的数据包标识传输的结束,此包仍需要一个ACK来确认

1）文件写成功

2）文件读成功

b）异常终止

发送错误包导致传输终止，此包无需确认，也不需要重传.源端口错误包除外.。

1）WRQ丢失

2）RRQ丢失

3）读数据包丢失

4）写数据包丢失

5）写ACK丢失

6）读ACK丢失

7）错误终止

8）ACK错误

9）数据包序号错误

10）特殊错误

3）协议状态

A.Ready：

开始时无请求

B.IDLE：

等待对方发送读写请求

C.WAIT_R_RESP或WAIT_W_RESP：

等待传送文件响应原语

D.WAIT_FIRST_P或WAIT_NEXT_P:

等待第一个或下一个数据包

E.WAIT_ACK或WAIT_LAST_ACK:

等待ACK响应或最后的ACK确认

4）协议事件

A.定时器超时：

重发上一条请求原语

B.服务原语：

●RRQ、WRQ：

发送文件读写请求原语

●ReadFile_IND:

请求文件响应原语

C.PDU

文件请求读写PDU

●DATA：

数据包PDU

●ERR：

文件错误PDU

●ACK：

确认包PDU

5）协议变量

●Filename：

字符串型，记录被传送的文件名

●Tempseqno、sendseqno、recvseqno、seqno：

整型，取值范围1到512,记录发送数据包的序列号

●Mode：

字符串型，记录被传送文件的格式

●Errcode：

整型，错误代码，默认为0

●Errmsg:

字符串型，错误消息

●Length：

整型，数据长度

●Datastr：

字符串型,数据包内容

6）协议动作和谓词

六问题及解决

1.当客户端向服务器请求写入时,磁盘满无法写入的情况？

在服务器向磁盘提出写入时，磁盘应可以根据自己容量进行判断,向服务器发送是否可以写入，在该版本内默认接收到请求都可以写入,若无法写入就回复ERR包，结束此次传输。

2.当传输数据包时最大容量为512字节，发现超过512字节也可以继续传输？

对数据包长度进行判断，当超过512字节时，应提示错误，无法发送该数据包。

七实验总结

通过本次实验，我了解到TFTP协议优点是每个数据包大小固定，这样在内存分配处理的时候比较直接，实现简单，每个数据包都有确认机制，可以实现一定程度的可靠性。

缺点是传输效率不高，滑动窗口机制太简单，并且该窗口仅有一个包的大小，每次传输仅能完成一次。

TFTP的超时机制虽设定为60s后超时，但并没有实现，只能通过两次点击Transmit来达到超时重发目的.这次实验虽然完成度不高，但我还是认真的去了解了TFTP传输的整个过程，并读懂每条数据都是由谁发出或接收，在今后的实验中我会继续去完善这个实验。

附图（程序运行测试结果）

1.TFTP客户端

A.用户向客户端提出读请求ReadFile_RRQ（'

example’,'

octet’）,客户端收到该请求，并向服务器提出RRQ请求,服务器接收该请求并向客户端发出DATA（‘1’，‘内容’）,若第一个包长度为512字节，表示不为最后一个包，继续发送第二个包，不足512字节视为最后一个包。

客户端收到数据包，向服务器发送ACK，确认收到该包，同时在最后一个包确认后，通知用户。

B.用户向客户端提出WriteFile_REQ请求，客户端向服务器发出WRQ请求,等待服务器回复ACK，服务器回复ACK为0的包,确认可以写入，客户端接收从用户处写入的Readdata包内容，并将数据写入到服务器，服务器确认写入，回ACK,若ACK错误，将超时等待重发正确的ACK包，并通知用户已写入。

2.TFTP服务器

A.客户端向服务器发送RRQ请求，服务器通过69号端口监听，若接收该请求，服务器建立新的连接，服务器向磁盘发出ReadFile_RESP的请求，收到确认后，向客户端发送DATA包，客户端收到需回复ACK确认收到，，若ACK不正确，将超时等待重新接收正确的ACK包。

传输结束

B.客户端向服务器发出WRQ请求，服务器通过69号端口监听，若接收该请求，服务器建立新的连接，服务器向磁盘发出WriteFile_IND的请求,磁盘确认可以写入，向服务器发送WriteFile_RESP，服务器收到后告诉客户端可以写入的ACK为0的确认包，客户端向服务器发送数据包,不足512字节视为最后一个包,并回复正确ACK包确认收到。