TFTP协议的SDL设计与C实现

实验二TFTP协议的SDL设计与C实现班级小班序号姓名成绩一协议环境分析用户要求1)连接功能连接管理采用UDP面向无连接方式。安全性要求，只允许合法的用户建立连接，可靠性要求，性能要求。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)五种协议数据单元PDUA.数据格式读文件请求包：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RRQ、WRQ：文件请求读写PDUDATA：数据包PDUERR：文件错误PDUACK：确认包PDU5)协议变量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包确认收到。