TFTP协议的SDL设计与C实现(2021年整理)

（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）编辑整理：尊敬的读者朋友们： 这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对 文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（完整）TFTP协议的SDL设计 与C实现（word版可编辑修改）的内容能够给您的工作和学习带来便利。同时也真诚的希望收到 您的建议和反馈，这将是我们进步的源泉，前进的动力。本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快 业绩进步，以 下为（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）的全部内容。（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）实验二TFTP协议的SDL设计与C实现班级 _ 小班序号 姓名 成绩一协议环境分析 用户要求1） 连接功能连接管理采用UDP面向无连接方式安全性要求，只允许合法的用户建立连接，可靠性 要求,性能要求。2） 文件传输TFTP没有用户权限管理，用户不需要发送用户名或口令，只有文件的读或写权，权限 许可时，文件才能被传输。无证实方式。传输8位数据.通道性质：TFTP客户机和服务器之间的通信是基于UDP/IP协议。工作模式：TFTP不支持交互，也没有命令集，因此不允许用户列出目录的内容或者与服务 器进行交互，判断可用的文件名称.TFTP使用客户服务器模式，一般支持两种传输模式： 是,netascii,即8比特ASCI I码;二是,0ctet，即8比特字节.可对文件进行读或写。二协议功能分析 传输开始于客户端发送一个文件读（下载）或写（上载）请求服务器使用UDP69号端口接收读/写请求，并建立一个新的连接支持两种数据传输模式netascii和octet每次传送的数据PDU包含定长512字节数据，不足512字节视为文件的最后一包数据，表示传输结束。 每块数据按序编号，从1开始（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）双方都提供确认机制，都提供超时重传 差错包导致传输终止（除源端口错误外），此包无需确认，无需重传 无校验机制:按宮户塔轉止脸务）|执行相应#菲I*监听端I】A. SDL 功能图B. 进程图 IfilenameLslrhg delm.Mrinfli.process servsf_lstenRROJienar-ierTwde)R&adyis証&eer_cwnRQiilename.modei bocnpnngId offspring三 协议结构设计分类接收实体和发送实体分层客户端和服务端用户通道接口子层四 协议机制设计流控机制：每个数据包包括一个数据块，客户只有等到服务器的一个确认包以后才会发送 下一个数据包，如果一个数据包小于 512 字节，则表示传输结束。 转发、确认机制：发送者每次只能发送一个包，以使确认机制可以保证以前发送的包都已 经收到.在一个传输过程中,通信双方既是发送者又是接收者，一方传输数据接收确认，另 一方发送确认接收数据. 错误机制:有许多错误可以导致连接终止，错误用发送错误包的形式通知对方 ,此包不会被 确认，也不需要重传.如果错误包丢失，则使用超时机制检测。有以下 8种错误：ErrorMsgs0 - hot defined1 - File hot found2 - Access sinhtion3 - Disk lull4 - Illegal TFTP opcratLon5 - Unknown port6 - File already exists.7 - no such user 超时机制:如果一个包（数据包或确认包）在传输过程中丢失，定时器将会超时，并重发上一个包五 协议元素设计1） 服务原语和服务原语时序初始连接时需要发出WRQ （请求写入）或RRQ （请求读取），收到一个确定应答,一个确 定可以写出的包或应该读取的第一块数据，通常确认包包括要确认的包的包号，每个数据 包都与一个块号相对应，块号从1开始而且是连续的.因此对于写入请求的确定是一个比较 特殊的情况，因此它的包号是0。如果收到的包是一个错误的包，则这个请求被拒绝. 需要四条服务原语： 读写请求：WRQ、RRQ （filename文件名，mode文件格式）指示：Data （seqno为序号，data为文件内容） 响应：ReadFile_RESP（filename为文件名，mode为文件格式） 证实：ACK（seqno为序号+1）读U诒求?KACK-ACK-TFTP客户端IFTP販务器TKvfrOIlSrndto:vftcfiFendtsTKlfLQri散据也l送失、jsendtaSandroACK （丢先）.J4CVfLQEl2）五种协议数据单元PDUA. 数据格式读文件请求包:Read request，简写为RRQ，客户端发送RRQ报文，服务器响应DATA报文01Fi 1 enaine0Mode0（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）写文件请求包:Write request，简写为WRQ，存储文件请求，服务器响应块号为0的ACK报文，客户端收到确认后，发送块号为1的第一个数据包02Fi 1 enaine0Mode0文件数据包:DATA，发送数据包，数据用DATA报文发送后，等待ACK报文，如果发送端在超时前收到ACK报文就发送下一个数据块，否则重传未被确认的数据包文02Block#Data 0 to 512 bytes 确认包：Acknowledgement，简写为ACK，数据确认报文04Block#差错包：ERROR，出错报文05Err codeError Msg0B. PDU交换时序a） 正常终止一个包含0511字节数据的数据包标识传输的结束，此包仍需要一个ACK来确认1） 文件写成功MSiterleOK2） 文件读成功b） 异常终止发送错误包导致传输终止，此包无需确认，也不需要重传.源端口错误包除外.1) WRQ 丢失2) RRQ 丢失MSC RRQLlKt读数据包丢失3)4)5)写数据包丢失写 ACK 丢失snw lisianMSC ACKLost6) 读 ACK 丢失7） 错误终止8) ACK 错误MSC ACKE临ye lislen9） 数据包序号错误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） 协议变量 File name :字符串型，记录被传送的文件名到 512,记录发送数据 Tempseqno、sendseqno、recvseqno、seqno： 整型，取值范围包的序列号 Mode：字符串型，记录被传送文件的格式 Errcode：整型，错误代码，默认为0 Errmsg:字符串型，错误消息 Length :整型，数据长度 Datastr :字符串型，数据包内容6） 协议动作和谓词六 问题及解决1. 当客户端向服务器请求写入时,磁盘满无法写入的情况？ 在服务器向磁盘提出写入时，磁盘应可以根据自己容量进行判断,向服务器发送是否可以写 入，在该版本内默认接收到请求都可以写入，若无法写入就回复ERR包，结束此次传输。2. 当传输数据包时最大容量为 512 字节，发现超过 512 字节也可以继续传输？ 对数据包长度进行判断，当超过 512字节时，应提示错误，无法发送该数据包。七 实验总结通过本次实验，我了解到 TFTP 协议优点是每个数据包大小固定，这样在内存分配处理的时 候比较直接，实现简单，每个数据包都有确认机制，可以实现一定程度的可靠性。缺点是传输 效率不高，滑动窗口机制太简单，并且该窗口仅有一个包的大小，每次传输仅能完成一次。TFTP 的超时机制虽设定为 60s 后超时，但并没有实现，只能通过两次点击 Transmit 来达到超时重 发目的这次实验虽然完成度不高，但我还是认真的去了解了 TFTP传输的整个过程，并读懂每 条数据都是由谁发出或接收，在今后的实验中我会继续去完善这个实验。附图（程序运行测试结果）1. TFTP 客户端（完整）TFTP协议的SDL设计与C实现（word版可编辑修改）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包确认收到。