TFTP协议的SDL设计与C实现整理.docx
- 文档编号:4084574
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:17
- 大小:446.61KB
TFTP协议的SDL设计与C实现整理.docx
《TFTP协议的SDL设计与C实现整理.docx》由会员分享,可在线阅读,更多相关《TFTP协议的SDL设计与C实现整理.docx(17页珍藏版)》请在冰点文库上搜索。
TFTP协议的SDL设计与C实现整理
(完整)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比特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
●RRQ、WRQ:
文件请求读写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包确认收到。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TFTP 协议 SDL 设计 实现 整理