TFTP协议需求分析(最终版).docxVIP

TFTP协议的SDL设计与C/C++实现1　引言1．1目的　　此协议设计的时候是进行小文件传输的。因此它不具备通常的FTP的许多功能，它只能从文件服务器上获得或写入文件，不能列出目录，不进行认证，它传输8位数据。传输中有三种模式：netascii，这是8位的ASCII码形式，另一种是octet，这是8位源数据类型；最后一种mail已经不再支持，它将返回的数据直接返回给用户而不是保存为文件。2　任务概述2．1建立TFTP协议　　因为TFTP使用UDP，而UDP使用IP，IP可以还使用其它本地通信方法。因此一个TFTP包中会有以下几段：本地媒介头，IP头，数据报头，TFTP 头，剩下的就是TFTP数据了。TFTP在IP头中不指定任何数据，但是它使用UDP中的源和目标端口以及包长度域。由TFTP使用的包标记（TID）在这里被用做端口，因此TID必须介于0到65,535之间。对它的初始化我们在后面讨论。TFTP头中包括两上字节的操作码|2．2用户的特点　　有软件工程基础知识，拥有对当前文件的读写权。2．3背景　　这个协议原本由Noel Chiappa设计，由Noel Chiappa、 Bob Baldwin和Dave Clark重新设计，并由Steve Szymanski 校验。现在的这个版本， Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David Reed, Craig Milo Rogers, Kathy Yellick和原本作者进行了修订。转发和确认机制受到TCP的影响，错误机制受 PARC的EFTP异常消息。现由我们开发小组重新制作。3　需求分析3．1对功能分析　　任何传输起自一个读取或写入文件的请求，这个请求也是连接请求。如果服务器批准此请求，连接就建立了，数据以定长512字节传输。每个数据包包括一块数据，发出下一个数据包以前必须得到对上一个数据包的确认。如果一个数据包的大小小于512字节，则表示传输结束。如果数据包在传输过程中丢失，发出方会在超时后重新传输最后一个未被确认的数据包。通信的双方都是数据的发出者与接收者，一方传输数据接收应答，另一方发出应答接收数据。　3．2对设备的要求1、PC with Windows XP/2003系列2、Telelogic Tau4.3 SDL Suite3、Microsoft VC++6.03.3对环境的分析用户要求：TFTP没有用户权限管理，用户不需要发送用户名或口令，只有文件的读或写权，权限许可时，文件才能被传输。连接管理采用UDP面向无连接方式。无证实方式。传输8位数据。安全性要求，只允许合法的用户建立连接，可靠性要求，性能要求。通道性质：TFTP客户机和服务器之间的通信是基于UDP协议工作模式：TFTP不支持互交，也没有命令集，因此不允许用户列出目录的内容或与服务器进行交互，判断可用的文件名称。3．4故障处理要求　　大部分的错误会导致连接中断，错误由一个错误的数据包引起。这个包不会被确认，也不会被重新发送，因此另一方无法接收到, 这种连接中断可以由超时机制来检查。错误主要是由下面三种情况引起的：不能满足请求；收到的数据包内容错误，而这种错误不能由延时或重发解释；对需要资源的访问丢失（如硬盘满）。TFTP只在一种作物情况下不中断连接，这种情况是源端口不正确，在这种情况下，指示错误的包会被发送到源机。这个协议限制很多，这是都是为了实现起来比较方便而进行的。例如，固定的长度方便本地存储，对每一个数据报进行确认方便流式控制和对接受的数据包进行排序。3．5其他专门要求　　可维护性、可补充性、易读性、可靠性。4 TFTP机制4.1TFTP的流控机制：TFTP的流控机制是一种数据流控机制，它要求发送端必须收到接收端对前面数据的确认后才能发出后面的数据。比如：当窗口大小等于三时，发送端发出三个数据段后，它必须等待对方确认后，才到发送后面的三个数据，如果由于某种原因，如缓冲区溢出，接收端没有收到数据，便不会发出确认，所以发送端便不会收到确认，这时发送端就知道刚才的数据过大必须重传，并且窗口要进行减小才能进行正常发送。4.2TFTP的转发、确认机制：转发和确认机制受到TCP的影响4.3TFTP的错误机制：错误机制受 PARC的EFTP异常消息。TFTP的超时机制：另一方无法接收到, 这种连接中断可以由超时机制来检查。5 TFTP协议结构Type Op #没有包头的格式2 bytes string 1 byte string 1 byte-----------------------------------------------RRQ/ | 01/02 | Filename |