FTP協(xié)議RFC中英文文文檔

FTP協(xié)議概念：FTPFTP是TCP/IP協(xié)議組中的協(xié)議之一，是英文FileTransferProtocol該協(xié)議是Internet文件傳送的根底，它由一系列規(guī)格說明文檔組成，目標是提高文件的共享性，供給非直接使用遠程計算機FTP載〔download〕”〔upload〕”文件。在TCP/IP協(xié)議中，F(xiàn)TP標準命令TCP端口號為21，Port方式數(shù)據(jù)端口為20。FTP的目標是：1〕促進程序/數(shù)據(jù)文件的共享；2〕鼓舞〔通過程序〕使用遠程計算機3〕使用戶不必面對不同主機上不同文件系統(tǒng)的差異；4〕對數(shù)據(jù)進展高效牢靠的傳輸。FTP盡管可以直接在終端上應(yīng)用，但它主要被設(shè)計通過程序來使用。數(shù)據(jù)由發(fā)送端主機存儲設(shè)備傳輸?shù)浇邮斩酥鳈C的存儲設(shè)備上。由于兩個系統(tǒng)的數(shù)據(jù)存NVT-ASCII在不同的系統(tǒng)中有不同的存儲表示。DECTOP-20一般用5個7位的ASCII字符存儲NVT-ASCII，左對齊成36位的字。IBMMainframe用8位EBCDIC編碼存儲NVT-ASCII。Multics將NVT-ASCII存儲成4個9位NVT-ASCII和接收端則應(yīng)相應(yīng)地在標準表示法和內(nèi)部表示法間轉(zhuǎn)換個問題就是不同主機有不同的字長度收數(shù)據(jù)。例如，當從一個32位字長的系統(tǒng)傳輸32位字節(jié)到一個36位字長的系統(tǒng)時，應(yīng)當〔為了高效和有用在后一個系統(tǒng)中將32位字節(jié)在36都應(yīng)當可以選擇數(shù)據(jù)表示形式和傳輸功能。應(yīng)當留意FTP供給了格外有限的數(shù)據(jù)表示形式。傳輸這些表示形式之外的數(shù)據(jù)時用戶應(yīng)當自行轉(zhuǎn)換。RFC一、傳輸模式流模式數(shù)據(jù)以字節(jié)流傳輸。對表示類型沒有限制；可以使用記錄構(gòu)造。在記錄構(gòu)造文件中，EOR和EOF將分別用兩個字節(jié)的把握碼表示。第一個字節(jié)都是同樣的escape字符。其次個字節(jié)中，EOR將低位置一，其他位置零；EOF則是將其次低位置一；也就是這個字節(jié)對于EOR來說是1，對于EOF來說是2EOR和EOF可能在傳輸完畢時通過使〔就是值escapeEO塊模式〔沒有填充位文件最終一塊〔EOF〕，記錄最終塊〔EOR〕，重開頭標記〔參見錯誤恢復(fù)和重開頭章〕或者〔也就是被疑心在傳輸中可能不行靠的數(shù)據(jù)。最終的描述符不是FTP錯誤把握的〔比方地震或天氣數(shù)據(jù)〔比如磁帶讀錯誤〕3個字節(jié)。在這24位的頭信息中，低16位表示字節(jié)記數(shù)，高8位表示描述符。二、文件傳送功能下面的命令表示訪問把握標識符〔括號中表示命令代碼〕用戶名〔USER〕這個命令的參數(shù)域是一個用來標識用戶的Telnet字符串。用戶識別對于效勞器把握文件了轉(zhuǎn)變把握權(quán)限和/或帳戶信息，效勞器可能在任何時候都允許承受一個的USER原來的訪問把握權(quán)限下完成。密碼〔PASS〕這個命令的參數(shù)域是一個用來指定用戶密碼的Telnet字符串。這個命令必需緊跟在用戶名命令之后，在某些站點上，它用來完成用戶訪問權(quán)限識別。由于密碼信息格外敏感，一的密碼信息就成了用戶FTP帳戶〔ACCT〕這個命令的參數(shù)域是一個用來識別用戶帳戶的Telnet字符串。這個命令不需要和USER狀況：當?shù)卿涍^程必需要求帳戶信息的時候，PASS命令成功的響應(yīng)代碼是332。相應(yīng)，假設(shè)登錄過程不要求帳戶信息時，PASS命令成功的響應(yīng)代碼是230；假設(shè)帳戶信息需要在隨后的對話命令中給出，效勞器應(yīng)當依據(jù)是保存〔等侍收到ACCT命令〕還是放棄命令來相應(yīng)的返回332532。轉(zhuǎn)變工作名目〔CWD〕這個命令允許用戶在不轉(zhuǎn)變登錄用戶和帳戶信息的狀況下轉(zhuǎn)變工作名目或數(shù)據(jù)集組名。返回上層名目〔CDUP〕這個命令是CWD命令的特例，由于在不同的操作系統(tǒng)下表達父名目可能有不同的語法，CWD的響應(yīng)代碼一樣。更多信息參看附錄II。構(gòu)造裝備〔SMNT〕這個命令允許用戶在不轉(zhuǎn)變用戶和帳戶信息的狀況下裝備一個不同的文件系統(tǒng)數(shù)據(jù)結(jié)徑名。重初始化〔REIN〕此命令除允許當前正在傳輸過程完成外，終止一個用戶，刷全部的I/O和帳戶信息。之后可能需要USER注銷(QUIT)同的用戶名傳輸文件，而不想關(guān)閉然后再重建立連接的狀況下，應(yīng)當使用REIN命令而不是QUIT。把握連接的意外關(guān)閉將會導(dǎo)致效勞器產(chǎn)生等同于放棄〔ABOR〕和注銷〔QUIT〕動作。三、FTPFTP效勞命令定義了用戶懇求傳送文件或者文件系統(tǒng)的功能FTP效勞命令的參數(shù)一般〔盡量用默認標準和把握連接的語言“renamefrom“命令后面必需緊跟“renameto“命令以及restart命令必需緊跟隨中斷效勞命令。追加(包括創(chuàng)立)(APPE)這個命令引起效勞DTP承受從數(shù)據(jù)連接傳送過來的數(shù)據(jù)并存儲在效勞器端的一個文件會創(chuàng)立這個文件。安排(ALLO)一些效勞器可能要求用這個命令來保存足夠的空間來容納文件用來指定保存給文件存儲用的字節(jié)數(shù)〔用規(guī)律字節(jié)長度)。對于用記錄或者而構(gòu)造傳送的文件而言，還需要有最大構(gòu)造或頁的大小〔使用規(guī)律字節(jié)，這個值在這個命令的其次個參數(shù)Telne字符<SP>R<SP>和第一個參數(shù)分開。這個命令之后應(yīng)當是STOR或者APPE命令。在那些不需要預(yù)NOOP頁最大值感興趣的效勞器上應(yīng)當無視第一個參數(shù)。重開頭(REST)這個命令的參數(shù)域指定了需要重開頭傳輸?shù)奈募奈恢脴擞浀膫鬏?，只是無視文件中指定標記點前的數(shù)據(jù)。重命名開頭〔RNFR〕這個命令指定了需要重命名的文件的原始路徑名。后面必需馬上接著“重命名為”命令，來指定的文件路徑重命名為〔RNTO〕重命名。放棄〔ABOR〕該命令告知效勞器放棄從前的FTP效勞命令和相關(guān)的傳輸?shù)臄?shù)據(jù)效勞器的“特別留意”〔參見FTP命令局部〕，使效勞器強制識別。當前一個命令〔包括數(shù)據(jù)傳輸〕完成時，將不會產(chǎn)生動作。效勞器不會關(guān)閉把握連接，但是數(shù)據(jù)連接必需關(guān)閉。效勞器接收這個命令時可能處在兩種狀態(tài)：(1)FTP(2)FTP效勞命令還在執(zhí)行中。第一種狀況，效勞器關(guān)閉數(shù)據(jù)連接〔假設(shè)數(shù)據(jù)連接是翻開的回應(yīng)226代碼，表示放棄命令已經(jīng)成功處理。FTP426響應(yīng)代碼，表示懇求效勞懇求特別終止。然后效勞器發(fā)送226響應(yīng)代碼，表示放棄命令成功處理。刪除(DELE)這個命令在效勞器端刪除指定的文件FTP進程供給。刪除名目〔RMD〕〔假設(shè)是確定路徑〔假設(shè)是相對路徑〕。參看附錄II建名目〔MKD〕〔假設(shè)是確定路徑〔假設(shè)路徑是相對的〕。打印工作名目〔PWD〕該命令返回一個當前的工作名目名。列表〔LIST〕該命令從效勞器端發(fā)送一個列表到被動的DTPASCII或EBCDIC類型傳輸?！灿脩舯匦璐_定類型是ASCII或者EBCDIC〕。由于不同系統(tǒng)間的文件信息差異很大，這個信息可能不易被程序自動使用，但可能對于用戶來說是有用處的。名字列表〔NLST〕該命令從效勞器端傳送名目列表到用戶端的信息。數(shù)據(jù)將通過數(shù)據(jù)連接以ASCII或者EBCDIC類型傳輸，每個路徑名字符串由<CRLF>或<NL〔用戶仍必需保證類型使用正確〕文件的自動處理。例如，多線程下載的實現(xiàn)。站點參數(shù)〔SITE〕處不是很普遍。效勞的種類和語法規(guī)約可以在HELPSITE命令的響應(yīng)中確定。系統(tǒng)〔SYST〕該命令來得到效勞器端操作系統(tǒng)的類型。響應(yīng)的第一個詞應(yīng)當是AssignedNumbers文檔。狀態(tài)〔STAT〕該命令應(yīng)當通過把握連接以響應(yīng)碼的形式返回狀態(tài)信息發(fā)出〔與TelnetIP和同步信號一起，參見FTP命令道聽局部〕，此時效勞器將返回正在傳FTP前值和連接的狀態(tài)。幫助〔HELP〕該命令使效勞器通過把握連接傳送關(guān)于具體實現(xiàn)狀態(tài)的幫助信息給用戶〔211或者214USER命令前允許HELPHELPSITE響應(yīng)中指定?？詹僮鳌睳OOP〕器返回OKTelnetTelnet傳輸使用的語言可能是一個可協(xié)商的選項，下兩局部提到的全部參考信息將使用“Telnet語言”和相應(yīng)的“Telnet行尾符”。固然可以將這些轉(zhuǎn)換成NVT-ASCII和<CRLF>。沒有其它的TelnetFTPFTP效勞懇求命令三種。某些命令不的指令格式是試驗性建議：1.用戶系統(tǒng)在Telnet流中插入Telnet“中斷過程“〔InterruptProcess-IP〕信號2.用戶系統(tǒng)發(fā)出Telnet〔Synch〕信號用戶系統(tǒng)在Telnet流中插入命令〔例如，ABOR〕效勞器PI，在接收到“IP“后，掃描telnet流，查找FTP命令五、FTP合。比方USER、PASS和ACCT，或者RNFR和RNTO。此時的響應(yīng)表示一種中間狀態(tài)，說明前面應(yīng)序列的細節(jié)，將由下面一組狀態(tài)圖說明確表示。FTP響應(yīng)由3〔以3個數(shù)字字符傳遞PI不3位數(shù)字，后面跟著空格<SP>，然后是一行文本〔已指定一行最大的長度〕，以Telnet行末符結(jié)尾。有可能消滅文本長度大于一行的狀況應(yīng)〔也就是，停頓從把握連接讀取輸入〕，去做別的事情。這要求第一行文本需要一種特別一樣的。因此，多行回應(yīng)的格式是：第一行以正常的響應(yīng)代碼開頭，后接連字符“-”〔也就是那個減號<SP>分的可選文本，然后是Telnet行末符用戶進程只需要簡潔地查找一行開頭時后面跟隨〔空格〕3位數(shù)字，效勞器必須在前面填充，以避開混淆。添加“人工的”第一行和最終一行標志的這種方案，允許使用標準系統(tǒng)例行程序產(chǎn)生響應(yīng)信息〔例如，產(chǎn)生STAT響應(yīng)〕。少數(shù)狀況下，假設(shè)例行程序必需在某一行行首生成33位數(shù)字的每一位都有特定的意義。允許用戶進程將簡潔〔參見狀態(tài)圖〕，簡潔的用戶進程可以通過檢查第一位數(shù)字，打算它的下一個動作〔依打算處理，重試，放棄等等〕。用戶進程假設(shè)期望知道或許是發(fā)生了什么錯誤〔比方，文件系統(tǒng)錯誤，語法錯誤〕，可以通過檢查〔RNTORNFR命令。響應(yīng)的第一位數(shù)字可能有以下五個值：1yz，預(yù)備狀態(tài)〔用戶進程在接收到完成響應(yīng)前就發(fā)送另一條命令是違返協(xié)議的。但效勞器FTP進程在處理前面命令的過程中應(yīng)當〕FTP進程最多每個命令發(fā)送一個1yz代碼。2yz，完成狀態(tài)懇求動作被成功的完成。一個的懇求可以開頭。3yz，中間狀態(tài)一個命令來指定這個信息。這個回應(yīng)用在命令組合中。4yz，臨時拒絕狀態(tài)求。用戶應(yīng)當重回到命令隊列的開頭。說明“臨時”的具體意思是很困難的，尤其在兩個〔效勞器和用戶進程4yz號響應(yīng)可能于4yz號還是5yz號的一個規(guī)章是看這個命令是否可以不加修改并在一樣的用戶態(tài)下〔比方，命令使用同樣的拼寫使用同樣的參數(shù)；用戶不轉(zhuǎn)變文件訪問權(quán)限；效勞器不產(chǎn)生的實現(xiàn)?！吃俅沃貜?fù)。5yz,永久拒絕狀態(tài)〔包括同樣的命令順序〕。一些“永久的”錯誤狀態(tài)可以被修正，因此人類用戶或許期望把握用戶進程在將來的某點上重開頭命令隊列。〔比方在拼寫轉(zhuǎn)變之后，或名目狀態(tài)轉(zhuǎn)變之后?！车谌粩?shù)字為其次位數(shù)字指定的狀態(tài)供給了更具體的意義。下面的響應(yīng)列表會說明這一點。留意，每一個響應(yīng)的對應(yīng)文本只是推舉的，而非強制性的，可依照相應(yīng)的命令而更改方面，響應(yīng)代碼，必需嚴格的遵守最終局部的標準，也就是說，效勞器實現(xiàn)不應(yīng)當為與上面所描述的只有微小區(qū)分的狀態(tài)制造的代碼TYPE或ALLO這樣的成功執(zhí)行也不會給用戶進程信息的命令將產(chǎn)生200系統(tǒng)無關(guān)而不必被效勞器FTPALLO在TOPS20202號響應(yīng)用來處理這種狀況，例如，響應(yīng)文本為“Nostorageallocationnecessary”〔無需安排存儲〕。另外，假設(shè)，假設(shè)502。504，說明實現(xiàn)了此命令，但是懇求的參數(shù)并未被實現(xiàn)。六、連接效勞器PI在端口LPI發(fā)起一個雙向的把握連接。效勞端和用戶端進程都應(yīng)當遵守ARPA-InternetProtocolHandbook[1]中描述的Telnet協(xié)議。效勞器候，把握連接應(yīng)當在用戶的懇求下由效勞器關(guān)閉。用戶DTP必需在指定的數(shù)據(jù)端口上“監(jiān)聽”；這個端口可能是默認的用戶端口(U)或者由PORT(L-1)發(fā)起一個到用戶指定數(shù)據(jù)端口FTPFTP實現(xiàn)必需支持使用默認的端口進展數(shù)據(jù)傳送，并且只有用戶PI可以發(fā)起使用非默認端口。當數(shù)據(jù)在兩個效勞器A和B〔參考圖2〕間傳輸時,由用戶PI，C，建立到兩個效勞器的把握連接。然后，C發(fā)送PASV命令給效勞器A,讓效勞器A在數(shù)據(jù)端口上“監(jiān)聽”,而不是在收到傳輸效勞命令后主動發(fā)起連接。效勞器A對PASV命令的響應(yīng)它包括了正在監(jiān)聽的主機IPPI通過PORT命令發(fā)送效勞器A的端口a到效勞器B。BPI可能會發(fā)送相關(guān)的效勞命令給效勞器A和效勞器B。效勞器B發(fā)起連接并開頭傳輸。下面列出到下一個傳輸命令是不允許的，由于用戶進程要檢查數(shù)據(jù)連接來確定是否要開頭“監(jiān)聽”。為了防止混亂，關(guān)閉數(shù)據(jù)連接后效勞器發(fā)送響應(yīng)226〔或者假設(shè)連接保持翻開狀態(tài)，發(fā)送一個“文件傳送完成“的應(yīng)答(250)并且在發(fā)出一個的傳輸命令之前用戶PI應(yīng)當?shù)却渲械囊粋€響應(yīng))。任何時候，當用戶端或者效勞器端覺察連接將要被另一端關(guān)閉時，應(yīng)當馬上讀取還在連接隊列中的剩余數(shù)據(jù)，然后再執(zhí)行關(guān)閉。命令和響應(yīng)挨次FTP命令，效勞34否成功。的二級次要回復(fù)。一組很重要的信息響應(yīng)是連接問候220“等待輸入“的響應(yīng)。用戶應(yīng)當在發(fā)送任何命令之前等待這個問候消息。假設(shè)效勞器不能馬上承受輸入，會馬上發(fā)送一個120“期盼推遲“，當預(yù)備好后會發(fā)送220號響應(yīng)。這樣用戶才不會由于延遲而停滯。自然響應(yīng)有時,“系統(tǒng)“會自發(fā)地發(fā)送一條消息給用戶(常常是全部用戶)。比方，“系統(tǒng)將在15分鐘之內(nèi)關(guān)閉“。像這種從效勞器發(fā)送到用戶的自發(fā)信息是無法預(yù)期的。建議這類信息放在效勞器具PI的隊列中并在下一次響應(yīng)時發(fā)送給用戶IP〔可能是多行回復(fù)〕。下面的表格列出來每個命令可能收到的成功或失敗的響應(yīng)。它們必需嚴格依據(jù)下面的說明：效勞器可以修改響應(yīng)的文字說明，但是命令響應(yīng)代碼的意義不能轉(zhuǎn)變。命令響應(yīng)序列的完成響應(yīng)，最終是為后續(xù)命令預(yù)備的中間響應(yīng)。協(xié)議RFC英文文檔：INTRODUCTIONTheobjectivesofFTPare1)topromotesharingoffiles(computerprogramsand/ordata),2)toencourageindirectorimplicit(viaprograms)useofremotecomputers,3)toshieldauserfromvariationsinfilestoragesystemsamonghosts,and4)totransferdatareliablyandefficiently.FTP,thoughusabledirectlybyauserataterminal,isdesignedmainlyforusebyprograms.Theattemptinthisspecificationistosatisfythediverseneedsofusersofmaxi-hosts,mini-hosts,personalworkstations,andTACs,withasimple,andeasilyimplementedprotocoldesign.ThispaperassumesknowledgeoftheTransmissionControlProtocol(TCP)[2]andtheTelnetProtocol[3].ThesedocumentsarecontainedintheARPA-Internetprotocolhandbook[1].OVERVIEWInthissection,thehistory,theterminology,andtheFTPmodelarediscussed.ThetermsdefinedinthissectionareonlythosethathavespecialsignificanceinFTP.SomeoftheterminologyisveryspecifictotheFTPmodel;somereadersmaywishtoturntothesectionontheFTPmodelwhilereviewingtheterminology.HISTORYFTPhashadalongevolutionovertheyears.AppendixIIIisachronologicalcompilationofRequestforCommentsdocumentsrelatingtoFTP.Theseincludethefirstproposedfiletransfermechanismsin1971thatweredevelopedforimplementationonhostsatM.I.T.(RFC114),pluscommentsanddiscussioninRFC141.RFC172providedauser-levelorientedprotocolforfiletransferbetweenhostcomputers(includingterminalIMPs).ArevisionofthisasRFC265,restatedFTPforadditionalreview,whileRFC281suggestedfurtherchanges.Theuseofa“SetDataType“transactionwasproposedinRFC294inJanuary1982.RFC354obsoletedRFCs264and265.TheFileTransferProtocolwasnowdefinedasaprotocolforfiletransferbetweenHOSTsontheARPANET,withtheprimaryfunctionofFTPdefinedastransferingfilesefficientlyandreliablyamonghostsandallowingtheconvenientuseofremotefilestoragecapabilities.RFC385furthercommentedonerrors,emphasispoints,andadditionstotheprotocol,whileRFC414providedastatusreportontheworkingserveranduserFTPs.RFC430,issuedin1973,(amongotherRFCstoonumeroustomention)presentedfurthercommentsonFTP.Finally,an“official“FTPdocumentwaspublishedasRFC454.ByJuly1973,considerablechangesfromthelastversionsofFTPweremade,butthegeneralstructureremainedthesame.RFC542waspublishedasanew“official“specificationtoreflectthesechanges.However,manyimplementationsbasedontheolderspecificationwerenotupdated.In1974,RFCs607and614continuedcommentsonFTP.RFC624proposedfurtherdesignchangesandminormodifications.In1975,RFC686entitled,“LeavingWellEnoughAlone“,discussedthedifferencesbetweenalloftheearlyandlaterversionsofFTP.RFC691presentedaminorrevisionofRFC686,regardingthesubjectofprintfiles.MotivatedbythetransitionfromtheNCPtotheTCPastheunderlyingprotocol,aphoenixwasbornoutofalloftheaboveeffortsinRFC765asthespecificationofFTPforuseonTCP.ThiscurrenteditionoftheFTPspecificationisintendedtocorrectsomeminordocumentationerrors,toimprovetheexplanationofsomeprotocolfeatures,andtoaddsomenewoptionalcommands.Inparticular,thefollowingnewoptionalcommandsareincludedinthiseditionofthespecification:CDUP-ChangetoParentDirectorySMNT-StructureMountSTOU-StoreUniqueRMD-RemoveDirectoryMKD-MakeDirectoryPWD-PrintDirectorySYST-SystemThisspecificationiscompatiblewiththepreviousedition.Aprogramimplementedinconformancetothepreviousspecificationshouldautomaticallybeinconformancetothisspecification.ASCIITheASCIIcharactersetisasdefinedintheARPA-InternetProtocolHandbook.InFTP,ASCIIcharactersaredefinedtobethelowerhalfofaneight-bitcodeset(i.e.,themostsignificantbitiszero).accesscontrolsAccesscontrolsdefineusers”accessprivilegestotheuseofasystem,andtothefilesinthatsystem.Accesscontrolsarenecessarytopreventunauthorizedoraccidentaluseoffiles.Itistheprerogativeofaserver-FTPprocesstoinvokeaccesscontrols.bytesizeTherearetwobytesizesofinterestinFTP:thelogicalbytesizeofthefile,andthetransferbytesizeusedforthetransmissionofthedata.Thetransferbytesizeisalways8bits.Thetransferbytesizeisnotnecessarilythebytesizeinwhichdataistobestoredinasystem,northelogicalbytesizeforinterpretationofthestructureofthedata.controlconnectionThecommunicationpathbetweentheUSER-PIandSERVER-PIfortheexchangeofcommandsandreplies.ThisconnectionfollowstheTelnetProtocol.dataconnectionAfullduplexconnectionoverwhichdataistransferred,inaspecifiedmodeandtype.Thedatatransferredmaybeapartofafile,anentirefileoranumberoffiles.Thepathmaybebetweenaserver-DTPandauser-DTP,orbetweentwoserver-DTPs.dataportThepassivedatatransferprocess“l(fā)istens“onthedataportforaconnectionfromtheactivetransferprocessinordertoopenthedataconnection.DTPThedatatransferprocessestablishesandmanagesthedataconnection.TheDTPcanbepassiveoractive.End-of-LineTheend-of-linesequencedefinestheseparationofprintinglines.ThesequenceisCarriageReturn,followedbyLineFeed.EOFTheend-of-fileconditionthatdefinestheendofafilebeingtransferred.EORTheend-of-recordconditionthatdefinestheendofarecordbeingtransferred.errorrecoveryAprocedurethatallowsausertorecoverfromcertainerrorssuchasfailureofeitherhostsystemortransferprocess.InFTP,errorrecoverymayinvolverestartingafiletransferatagivencheckpoint.FTPcommandsAsetofcommandsthatcomprisethecontrolinformationflowingfromtheuser-FTPtotheserver-FTPprocess.fileAnorderedsetofcomputerdata(includingprograms),ofarbitrarylength,uniquelyidentifiedbyapathname.modeThemodeinwhichdataistobetransferredviathedataconnection.ThemodedefinesthedataformatduringtransferincludingEORandEOF.ThetransfermodesdefinedinFTParedescribedintheSectiononTransmissionModes.NVTTheNetworkVirtualTerminalasdefinedintheTelnetProtocol.NVFSTheNetworkVirtualFileSystem.Aconceptwhichdefinesastandardnetworkfilesystemwithstandardcommandsandpathnameconventions.Afilemaybestructuredasasetofindependentpartscalleds.FTPsupportsthetransmissionofdiscontinuousfilesasindependentindexeds.PathnamePathnameisdefinedtobethecharacterstringwhichmustbeinputtoafilesystembyauserinordertoidentifyafile.Pathnamenormallycontainsdeviceand/ordirectorynames,andfilenamespecification.FTPdoesnotyetspecifyastandardpathnameconvention.Eachusermustfollowthefilenamingconventionsofthefilesystemsinvolvedinthetransfer.PITheprotocolinterpreter.Theuserandserversidesoftheprotocolhavedistinctrolesimplementedinauser-PIandaserver-PI.recordAsequentialfilemaybestructuredasanumberofcontiguouspartscalledrecords.RecordstructuresaresupportedbyFTPbutafileneednothaverecordstructure.replyAreplyisanacknowledgment(positiveornegative)sentfromservertouserviathecontrolconnectioninresponsetoFTPcommands.Thegeneralformofareplyisacompletioncode(includingerrorcodes)followedbyatextstring.Thecodesareforusebyprogramsandthetextisusuallyintendedforhumanusers.server-DTPThedatatransferprocess,initsnormal“active“state,establishesthedataconnectionwiththe“l(fā)istening“dataport.Itsetsupparametersfortransferandstorage,andtransfersdataoncommandfromitsPI.TheDTPcanbeplacedina“passive“statetolistenfor,ratherthaninitiateaconnectio