TFTP協(xié)議需求分析(最終版)

1、tftp協(xié)議的sdl設(shè)計(jì)與c/c+實(shí)現(xiàn)1引言1. 1目的此協(xié)議設(shè)計(jì)的時(shí)候是進(jìn)行小文件傳輸?shù)?。因此它不具備通常的ftp的許多功能，它只 能從文件服務(wù)器上獲得或?qū)懭胛募荒芰谐瞿夸?，不進(jìn)行認(rèn)證，它傳輸8位數(shù)據(jù)。傳輸中 有三種模式：netascii ,這是8位的ascii碼形式，另一種是octet ,這是8位源數(shù)據(jù)類型； 最后一種mail已經(jīng)不再支持，它將返回的數(shù)據(jù)直接返回給用戶而不是保存為文件。2任務(wù)概述21建立tftp協(xié)議因?yàn)閠ftp使用udp ,而udp使用ip , ip可以還使用其它本地通信方法。因此一個(gè) tftp包中會(huì)有以下幾段：本地媒介頭，ip頭，數(shù)據(jù)報(bào)頭，tftp頭，剩下的就是tft

2、p數(shù) 據(jù)了。tftp在ip頭中不指定任何數(shù)據(jù)，但是它使用udp中的源和目標(biāo)端口以及包長度域。 由tftp使用的包標(biāo)記（tid）在這里被用做端口，因此tid必須介于0到65,535之間。對(duì) 它的初始化我們?cè)诤竺嬗懻摗ftp頭中包括兩上字節(jié)的操作碼|2. 2用戶的特點(diǎn)有軟件工程基礎(chǔ)知識(shí)，擁有對(duì)當(dāng)前文件的讀寫權(quán)。2. 3背景這個(gè)協(xié)議原本由 noel chiappa 設(shè)計(jì)，由 noel chiappa、 bob baldwin 和 dave clark 重新設(shè)計(jì)，并由steve szymanski校驗(yàn)?，F(xiàn)在的這個(gè)版本，lan*y allen, noel chiappa, dave clark, ge

3、off cooper, mike greenwald, liza martin, david reed, craig milo rogers, kathy yellick和原本作者進(jìn)行了修訂。轉(zhuǎn)發(fā)和確認(rèn)機(jī)制受到tcp的影響，錯(cuò)誤機(jī)制受parc的 e ftp異常消息?，F(xiàn)由我們開發(fā)小組重新制作。3需求分析3. 1對(duì)功能分析任何傳輸起自一個(gè)讀取或?qū)懭胛募恼?qǐng)求，這個(gè)請(qǐng)求也是連接請(qǐng)求。如果服務(wù)器批準(zhǔn)此 請(qǐng)求，連接就建立了，數(shù)據(jù)以定長512字節(jié)傳輸。每個(gè)數(shù)據(jù)包包括一塊數(shù)據(jù)，發(fā)出下一個(gè)數(shù) 據(jù)包以前必須得到對(duì)上一個(gè)數(shù)據(jù)包的確認(rèn)。如果一個(gè)數(shù)據(jù)包的大小小于512字節(jié)，則表示傳 輸結(jié)束。如果數(shù)據(jù)包在傳輸過程中丟失

4、，發(fā)出方會(huì)在超時(shí)后重新傳輸最后一個(gè)未被確認(rèn)的數(shù) 據(jù)包。通信的雙方都是數(shù)據(jù)的發(fā)出者與接收者，一方傳輸數(shù)據(jù)接收應(yīng)答，另一方發(fā)出應(yīng)答接 收數(shù)據(jù)。3. 2對(duì)設(shè)備的要求1、pc with windows xp/2003 系列2、t el elogic t au4.3 sd l suite3、microsoft vc+ +6.03. 3對(duì)環(huán)境的分析用戶要求:tftp沒有用戶權(quán)限管理，用戶不需要發(fā)送用戶名或口令，只有文件的讀或?qū)憴?quán)， 權(quán)限許可時(shí)，文件才能被傳輸。連接管理采用udp面向無連接方式。無證實(shí)方式。傳輸8 位數(shù)據(jù)。安全性要求，只允許合法的用戶建立連接，可靠性要求，性能要求。通道性質(zhì)：tftp客戶機(jī)和

5、服務(wù)器之間的通信是基于udp協(xié)議工作模式：tftp不支持互交，也沒有命令集，因此不允許用戶列出目錄的內(nèi)容或與服務(wù)器進(jìn)行交互，判斷可用的文件名稱。3. 4故障處理要求大部分的錯(cuò)誤會(huì)導(dǎo)致連接中斷，錯(cuò)誤由一個(gè)錯(cuò)誤的數(shù)據(jù)包引起。這個(gè)包不會(huì)被確認(rèn)，也 不會(huì)被重新發(fā)送，因此另一方無法接收到，這種連接中斷可以由超時(shí)機(jī)制來檢查。錯(cuò)誤主要 是由下面三種情況引起的：不能滿足請(qǐng)求；收到的數(shù)據(jù)包內(nèi)容錯(cuò)誤，而這種錯(cuò)誤不能由延時(shí) 或重發(fā)解釋；對(duì)需要資源的訪問丟失（如硬盤滿x tftp只在一種作物情況下不中斷連接， 這種情況是源端口不正確，在這種情況下，指示錯(cuò)誤的包會(huì)被發(fā)送到源機(jī)。這個(gè)協(xié)議限制很 多，這是都是為了實(shí)現(xiàn)起來比

6、較方便而進(jìn)行的。例如，固定的長度方便本地存儲(chǔ)，對(duì)每一 個(gè)數(shù)據(jù)報(bào)進(jìn)行確認(rèn)方便流式控制和對(duì)接受的數(shù)據(jù)包進(jìn)行排序。3. 5其他專門要求可維護(hù)性、可補(bǔ)充性、易讀性、可靠性。4 tftp機(jī)制4. 1 tftp的流控機(jī)制：tftp的流控機(jī)制是一種數(shù)據(jù)流控機(jī)制，它要求發(fā)送端必須收到接收端對(duì)前面數(shù)據(jù)的確認(rèn)后 才能發(fā)出后面的數(shù)據(jù)。比如：當(dāng)窗口大小等于三時(shí)，發(fā)送端發(fā)出三個(gè)數(shù)據(jù)段后，它必須等待對(duì)方確認(rèn)后，才到發(fā)送 后面的三個(gè)數(shù)據(jù)，如果由于某種原因，如緩沖區(qū)溢出，接收端沒有收到數(shù)據(jù)，便不會(huì)發(fā)出確 認(rèn)，所以發(fā)送端便不會(huì)收到確認(rèn)，這時(shí)發(fā)送端就知道剛才的數(shù)據(jù)過大必須重傳，并且窗口要 進(jìn)行減小才能進(jìn)行正常發(fā)送。4. 2tft

7、p的轉(zhuǎn)發(fā)、確認(rèn)機(jī)制：轉(zhuǎn)發(fā)和確認(rèn)機(jī)制受到tcp的影響4. 3tftp的錯(cuò)誤機(jī)制：錯(cuò)誤機(jī)制受parc的e ftp異常消息。tftp的超時(shí)機(jī)制:另一方無法接收到，這種連接中斷可以由超時(shí)機(jī)制來檢查。5 tftp協(xié)議結(jié)構(gòu)tftp 包客戶端服務(wù)器aa數(shù)據(jù)傳輸type op #沒有包頭的格式2 bytes string 1 byte string 1 byterrq/101/02| filename | 0 | mode | 0 |wrq2 bytes 2 bytes n bytesdata | 03 | block # | data |2 bytes 2 bytesack | 04 | block # |

8、2 bytes 2 bytes string 1 byteerror | 05 | errorcode | errmsg | 0 |5 tftp元素包tftp支持五種類型的包：1 read request (rrq)2 write request (wrq)3 data (data)4 acknowledgment (ack)5 error (error)包頭中包括了這個(gè)包所指定的操作碼。2 bytes string 1 byte string 1 bytei opcode | filename | 0 | mode | 0 |figure 5-1: rrq/wrq 包rrq和wrq包（代碼分

9、別為1和2）的格式如上所示。文件名是netascii碼字符，以0 結(jié)束。而mode域包括了字符串“netascii”，“octet“或”mail",名稱不分大小寫。接收到 netascii格式數(shù)據(jù)的主機(jī)必須將數(shù)據(jù)轉(zhuǎn)換為本地格式。octet模式用于傳輸在源機(jī)上以 8位格式存儲(chǔ)的文件。假設(shè)每個(gè)機(jī)器都存在一個(gè)8位的格式，這樣的假設(shè)是最一般的。比如 dec20 ,這是一種36位機(jī)，我們可以假設(shè)它是4個(gè)8位外加另外4位而構(gòu)成。如果機(jī)器收 到0ctet格式文件，返回時(shí)必須與原來文件完全一樣。在使用mail模式時(shí)，用戶可以在 file處使用接收人地址，這個(gè)地址可以是用戶名或用戶名主機(jī)的形式，如果是

10、后一種形 式，允許主機(jī)使用電子郵件傳輸此文件。如果使用mail類型，包必須以wrq幵始，否則 它與netascii完全一樣。我們的討論建立在發(fā)送方和接收方都在相同模式的情況下，但是雙方可以以不同的模式進(jìn)行 傳輸。例如一個(gè)機(jī)器可以是一臺(tái)存儲(chǔ)服務(wù)器，這樣一臺(tái)服務(wù)器需要將netascii格式轉(zhuǎn)換為 自己的格式。另外，我們可以設(shè)想dec-20這種機(jī)器，它使用36位字長，用戶這邊可以使 用特殊的機(jī)制一次讀取36位，而服務(wù)器卻可以仍然使用8位格式。在這兩種情況下，我們 看到了兩臺(tái)機(jī)器使用不同格式的情況。可以在兩臺(tái)主機(jī)間定義其它的傳輸方式，但是定義要 小心，因?yàn)檫@種傳輸方式不為人知，而且也沒有權(quán)威機(jī)構(gòu)為其指

11、定名稱或定義它的模式。2 bytes 2 bytes n bytesi opcode | block # | data |figure 5-2： data 包數(shù)據(jù)在數(shù)據(jù)包中傳輸，其格式如上圖所示。數(shù)據(jù)包的0p碼為3 ,它還包括有一個(gè)數(shù)據(jù)塊號(hào) 和數(shù)據(jù)。數(shù)據(jù)塊號(hào)域從1幵始編碼，每個(gè)數(shù)據(jù)塊加1 ,這樣接收方可以確定這個(gè)包是新數(shù)據(jù) 還是已經(jīng)接收過的數(shù)據(jù)。數(shù)據(jù)域從0字節(jié)到512字節(jié)。如果數(shù)據(jù)域是512字節(jié)則它不是最后 一個(gè)包，如果小于512字節(jié)則表示這個(gè)包是最后一個(gè)包。除了 ack和用于中斷的包外，其 它的包均得到確認(rèn)。發(fā)出新的數(shù)據(jù)包等于確認(rèn)上次的ack包。wrq和data包由ack或 e rror數(shù)據(jù)包確認(rèn)，而rrq和數(shù)據(jù)包由data或e rror數(shù)據(jù)包確認(rèn)。下圖即是一個(gè)ack 包，操作碼為4。其中的包號(hào)為要確認(rèn)的數(shù)據(jù)包的包號(hào)。2 bytes 2 bytes| opcode | block # |figure 5-3: ack 包wrq數(shù)據(jù)包被ack數(shù)據(jù)包確認(rèn)，wrq數(shù)據(jù)包的包號(hào)為0。2 bytes 2 bytes string