FILE TRANSFER PROTOCOL

Traducere de:
HAISAN ADRIAN - hasan@infoiasi.ro
si
CATALIN MIHAI APOSTU - bendis@infoiasi.ro

Network Working Group J. Postel
Request for Comments: 959 J. Reynolds
ISI
Obsoletes RFC: 765 (IEN 149) October 1985

FILE TRANSFER PROTOCOL (FTP)

Statutul acestui document

Acest document este specificatia oficiala a protocolului File Transfer
Protocol (FTP). Acest document se poate distribui nelimitat.

Urmatoarele noi comenzi optionale sunt incluse in aceasta editie a specificatiei :

CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
(Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
(Print Directory), and SYST (System).

Aceasta specificatie este compatibila cu editia precedenta.

1. Introducere

Scopurile protocolului FTP sunt :
1) sa promoveze ideea de partajare de informatii organizate in fisiere(programe
sau/si date)
2) sa incurajeze conexiunea implicita sau indirecta intre calculatoare aflate la
distanta ( prin intermediul programelor )
3) sa protejeze utilizatorul de variatiile dintre diferitele sisteme de operare de
pe calculatoare diferite
4) sa transfere date intre calculatoare diferite eficient si stabil

Acest protocol , desi poate fi folosit direct de utilizator la un terminal , este proiectat
in principal pentru a fi folosit de aplicatii.

Aceasta specificatie incearca sa satisfaca diversele nevoi de comunicare ale utilizatorilor
conectati la servere foarte mari , la servere mici , la calculatoare personale sau a celor
conectati la TAC cu un protocol simplu si usor implementat.

Acest document presupune cunoasterea protocolului TCP (Transmission Control Protocol )
[2] si a protocolului Telnet [3]. Aceste documente pot fi gasite in dictonarul de protocoale
ARPA-Internet [1].

2. SUMAR

In aceasta sectiune sunt descrise istoria, terminologia si modelul FTP. Tot aici sunt definiti
termenii care au o semnificatie speciala pentru FTP. O parte din terminologie este specifica
modelului FTP; unii cititori vor dori probabil sa treaca direct la sectiunea care prezinta modelul
FTP.

2.1. Istorie

Protocolul FTP a avut o evolutie lunga de-a lungul anilor. Sectiunea Appendix III este o
compilatie cronologica a diferitelor documente RFC legate de FTP de-a lungul timpului .
Acestea includ si primul mecanism de transfer fisiere din 1971 dezvoltat pentru
implementarea pe masinile de la M.I.T. (RFC 114), plus comentarii si discutii referitoare la
RFC 141.

RFC 172 furnizeaza un protocol orientat pe nivelul userului pentru transferul fisierelor
intre doua calculatoare ( inclusiv terminale IMPS ). O revizuire a acestui document este
RFC 265, iar in RFC 281 au fost propuse alte modificari . In ianuarie 1982 in RFC 294
a fost propusa folosirea conventiei "Set Data Type".

RFC 354 a inclocuit RFC 264 si 265. Protocolul FTP a fost redefinit ca un protocol pentru
transferul fisierelor intre calculatoare diferite din ARPANET, avand ca principala functie
transferarea eficienta si stabila a fiserelor intre calculatoare si care sa permita folosirea
usoara a metodelor de stocare la distanta.
RFC 385 a commentat erorile, a intarit unele idei si adaugiri la protocol, in timp ce
RFC 414 a adus un raport provind functionarea protocolului pe servere si pe calculatoare
personale. RFC 430, publicat in 1973 ( printre alte documente RFC ) a prezentat alte
sugestii. In cele din urma un document oficial a fost publicat sub numele de RFC 454.

Incepand cu iulie 1973 au fost facute schimbari considerabile de la ultimele versiuni
ale protocolului, dar structura generala a ramas neschimbata. RFC 542 a fost publicat ca
noua specificatie "oficiala" pentru a reflecta aceste schimbari. Exista si alte documente
bazate pe specificatiile vechi care nu au fost reinnoite.

In 1974 RFC 607 si 614 au adus modificari si sugestii noi. RFC 624 a facut acelasi
lucru si el. In 1975, a fost publiat RFC 686, care a fost intitulat "Leaving Well Enough Alone",
a discutat diferentele intre toate versiunile anterioare ale specificatiei. RFC 691 a prezentat
o revizuire minora a RFC 686 cu privire la tiparirea fisierelor.

Motivata de tranzitia de la NCP la TCP ca protocol de baza , FTP a renascut ca pasarea
pheonix din toate eforturile din RFC 765 pentru folosirea protocolului TCP .

Editia curenta a specificatiei FTP isi propune sa corecteze unele erori minore din
documentatie, sa imbunatateasca documentarea unor caracteristici ale protocolului si a
adaugat alte comenzi optionale.

In particular, urmatoarele comenzi optionale sunt incluse in editia curenta a specificatiei :

CDUP - Change to Parent Directory ( Schimba directorul in directorul parinte )

SMNT - Structure Mount

STOU - Store Unique

RMD - Remove Directory ( Sterge directorul )

MKD - Make Directory ( Creare director )

PWD - Print Directory ( Listeaza directorul )

SYST - System

Aceasta specificatie este compatibila cu edtitia predenta. O aplicatie implementata
in conformitate cu specificatia precedenta este automat in conformitate cu specificatia
curenta.

2.2. Terminologie

ASCII

Setul de caractere ASCII este cel definit in documentul ARPA-Internet Protocol Handbook.
In protocolul FTP, caracterele ASCII sunt definite ca fiind a doua parte dintr-un set de caractere
pe 8 biti ( cu bitul semnificativ zero ).

access controls ( controlul accesului )

Controlul accesului defineste privilegiile utilizatorului la utilizarea sistemului de operare
si a fisierelor in acel sistem de operare. Acest control este necesar pentru a preveni utilizarea
neautorizata si accidentala a fisierelor. Acest control este printre prerogativele unui proces de
tip server de FTP.

byte size ( marimea unui octet )

Exista doua marimi ale octetilor care ne intereseaza in tranferul FTP: marimea octetului
logic si marimea octetului de transfer utilizat pentru transmiterea informatiilor. Marimea octetului
de transfer este intotdeauna de 8 biti. Aceasta marime nu este in mod obligatoriu marimea
octetului stocat in sistemul de operare, si nici marimea logica a octetului rezultata de
interpretarea informatiei pe un calculator.

control connection ( conexiune de control )

Calea de comunicare intre USER-PI si SERVER-PI pentru schimbul de comenzi si raspunsuri.
Aceasta conexiune urmeaza Telnet Protocol ( protocolul TELNET ).

data connection ( conexinea de date )

O conexiune full duplex prin care informatia este transferata, intr-un mod specificat.
Infomatia transferata poate fi o parte dintr-un fisier, un fisier intreg sau mai multe fisiere.
Calea poate fi intre un server-DTP si un user-DTP, sau intre doua server-DTP.

data port ( portul de conexiune )

Procesul de transfer pasiv "asculta" la portul rezervat protocolului FTP pentru a realiza o
conexiune cu procesul de transfer activ pentru a deschide o sesiune de transfer.

DTP ( data transfer process )

Procesul de transfer al informatiei ( pe scurt DTP ) stabileste si controleaza conexiunea
de informatii. DTP poate fi activ sau pasiv.

End-of-Line ( sfarsit de linie )

Secventa de sfarsit de linie defineste separarea liniilor. Aceasta e formata din CR
( Carriage Return ) , urmata de LF ( Line Feed ).

EOF ( sfarsit de fisier )

Conditia de sfarsit de fisier ce defineste sfarsitul fisierului care se transfera.

EOR ( sfarsit de inregistrare )

Secventa de sfarsit de linie defineste separarea inregistrarilor care se transfera.

error recovery ( recuperarea dupa o eroare )

O procedura ce permite utilizatorului sa revina dupa aparitia unei erori cum ar fi
o eroare in ssistemul de operare al unuia dintre calculatoarele implicate in transfer
sau o eroare a procesului de transfer. In transferul FTP, recuperarea dupa o eroare
poate sa implice restartarea transferului de la un anumit punct.

FTP commands ( comenzi FTP )

Un set de comenzi prin care se realizeaza controlul informatiei de la procesul FTP
client la cel server.

file ( fisier )

O succesiune de informatii de lungime variabila identificata unic printr-o cale.

mode ( modul , tipul )

Modul in care informatia este transferata. Modul defineste formatul informatiei in
timpul transferului inclusiv EOR si EOF . Aceste tipuri de transfer sunt descrise in
sectiunea de moduri de transmisie ( Transmission Modes ).

NVT

Network Virtual Terminal asa cum este el definit in protocolul telnet ( Telnet Protocol ).

NVFS

Sistemul de fisiere NVFS (Network Virtual File System). Un concept care defineste
un sistem de fisiere pentru retea cu comenzi standard si cu conventii referitoare la
scrierea cailor spre fisiere.

page ( pagina )

Un fisier poate fi structurat sub forma unui set independent de parti numite pagini.
Protocolu FTP suporta transmiterea fisierelor discontinue sub forma unor pagini indexate.

pathname ( cale de acces )

Calea de acces este definita ca sirul de caractere folosit de sistemul de fisiere pentru a
identifica un fisier in mod unic. In mod normanl aceste cai contin numele dispozitivului
si/sau directorului si numele fisierului. FTP nu specifica inca un standard pentru caile de
acces. Fiecare client trebuie sa urmeze conventiile de nume ale sistemelor de operare
implicate in transfer.

PI ( interpretorul protocolului )

Clientul si server-ul au roluri diferite in implementarile user-PI si server-PI.

record ( inregistrare )

Un fisier poate fi structurat sub forma unui numar de parti continue numite inregistrari.
Inregistrarile sunt suportate de protocolul FTP dar un fisier nu trebuie sa fie neaparat
structurat in inregistrari.

reply ( rapsuns )

Un raspuns este o recunoastere ( pozitiva sau negativa ) trimisa de server prin
intermediul conexiunii de control in rapsuns la comenzile FTP. Forma generala a unui raspuns
este un paragraf de cod urmat de un text. Codul este pentru aplicatii iar textul este pentru
utilizatorul uman.

server-DTP

Procesul de transfer al informatiei, in starea normala "activa", stabileste conexiunea de
date cu portul care "asculta". Acesta seteaza parametrii pentru transfer si stocare, si
transfera informatia ca raspuns la comenzile PI. DTP-ul poate fi setat in starea pasiva pentru
a asculta portul, decat sa initieze o conexine pe port.

server-FTP process ( procesul server FTP )

Un proces sau set de procese care realizeaza transferul fisierelor in colaborare cu un
proces FTP client sau server. Functiile constau in interpretorul protocolului (PI) si a
procesului de transfer al informatiei (DTP).

server-PI

Interpretorul protocolului pe partea de server "acsculta" portul L pentru o conexiune
cu clientul PI. Acesta primeste comenzi FTP de la PI client, trimmte raspunsuri si
raspunde de serverul DTP.

type ( tip )

Tipul de reprezentare a informatiei folosit la transfer si stocare. Tipul implica anumite
transformari intre timpul stocarii si timpul transferului. Tipurile pentru reprezentare definite
pentru protocolul FTP sunt descrise in sectiunea "Stabilirea legaturii de date".

user ( client)

O persoana sau un proces care doreste sa foloseasca serviciul de transfer de fisiere.
Utilizatorul uman poate interactioneze direct cu un proces server FTP, dar este
recomandata folosirea unui process FTP client deoarece protocolul este proiectat pentru
folosire automata.

user-DTP

Procesul de transfer al informatiei "asculta" la portul de FTP pentru o conexiune cu
procesul server FTP. Daca doua servere transfera informatii intre ele la un moment dat,
clientul DTP este inactiv.

user-FTP process ( procesul de client FTP )

Un set de functii inclusiv un interpretor de protocol, un proces de transfer al
informatiei si o interfata cu utilizatorul care impreuna realizeaza transferul informatiei cu
unul sau mai multe procese de tip server FTP. Interfata cu utilizatorul permite folosirea
textului scris ca mijloc de comunicare cu utilizatorului.

user-PI

Interpretorul protocolului pe partea de client initiaza conexiuniea de control cu
procesul server FTPpe portul U, trimite comenzi FTP si comanda procesul de transfer
daca acesta face parte din transferul informatiei.

2.3. Modelul protocolului FTP

Cu definitiile de mai sus in minte, urmatorul model ( Figura 1) este diagrama unei
conexiuni FTP.

-------------
|/---------\|
||Interface || --------
|| cu utilizatorul |<--->| Utilizator |
|\----^----/| --------
---------- | | |
|/------\| Comenzi FTP |/----V----\|
||Server|<---------------->| Client ||
|| PI || Raspunsuri FTP || PI ||
|\--^---/| |\----^----/|
| | | | | |
-------- |/--V---\| Conexiune |/----V----\| --------
| Sistem |<--->|Server|<---------------->| User |<--->| Sistem |
|| de fisiere || DTP || de date || DTP || |de fisiere|
-------- |\------/| |\---------/| --------
---------- -------------

server-FTP client-FTP

NOTES: 1. Conexiunea poate fi folosita in ambele sensuri.
2. Nu este necesar ca legatura sa existe tot timpul.

Figure 1 Modelul utilizarii protocolului FTP

In diagrama din Figura 1, interpretorul protocolului pe partea de client initiaza
conexiunea de control . Conexiunea de control urmeaza protocolul Telnet. La comenzile
utilizatorului sunt generate comenzi standard de interpretorul protocolului de pe
partea de client si transmise procesului corespunzator de pe partea de server prin
intermediul conexiunii de control.( Utilizatorul poate stabili o conexiune de control
directa cu serverul FTP, de la un terminal TAC si poate denera comenzi FTP standard
independent,trecand peste procesul FTP client.) Raspunsuri standard la aceste comenzi
sunt transmise de catre interpretorul protocolului pe partea de server catre
corespondentul lui pe partea de client prin conexiunea de control.

Comenzi FTP specifica parametrii pentru conexiunea de date ( portul, modul de
transfer, tipul de reprezentare si structura ) si tipul operatiilor specifice sistemului
de operare ( send,retrieve, append,delete,etc). Procesul client DTP sau cel care
indeplineste functia sa trebuie sa asculte la portul specific, si serverul initiaza
conexiunea de date si conexiunea de transfer in concordanta cu parametrii specificati.
Trebuie specificat faptul ca portul de date nu trebuie sa fie pe aceeasi masina cu
cea care initiaza comenzile FTP prin conexiunea de control, dar clientul sau procesul
FTP client trebuie sa se asigure ca asculta portul corespunzator.

Trebuie specificat de asemenea faptul ca legatura de date poate fi folosita
pentru trimiterea simultana si primirea simultana de informatii. Alta situatie este cea
in care utilizatorul doreste sa transfer informatii intre doua host-uri, care sunt
diferite amandoua de calcultatorul utilizatorului. Acesta realizeaza o conexiune intre
cele doua host-uri . Astfel, controlul infomratiei este transferat interpretorului
protocolului pe parte de client dar informatia este transferata intre procesele de
transfer server.
In continuare este prezentat modelul acestei interactiuni server-server.

Control ------------ Control
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Conexiunea de date | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- Port (A) Port (B) --------------

Figure 2

Protocolul necesita ca in momentul in care transferul informatiei este se desfasoara
conexiunile de control sa fie deschise. Este de datoria utilizatorului sa ceara inchiderea
acestor conexiuni cand a terminat de folosit serviciul FTP, si este datoria serverului
sa faca acest lucru. Serverul poate sa inchida transfreul de informatii daca conexiunile
de control sunt inchise fara comanda.

Relatia dintre FTP si Telnet:

Protocolul FTP foloseste protocolul Telnet pentru realizarea coneziunii de control.
Acest lucru poate fi realizat in doua moduri: unul este cel in care interpretorul protocolului
pe partea de client sau cel de pe partea de server implementeaza regulile protocolului Telnet
direct in functiile pe care le folosesc; sau, a doua metoda interpretorul clientului sau cel
al serverului folosesc functiile implementate de Telnet.

Usurinta in implementare, cod reutilizabil si programare modulara sunt argumentele
pentru folosirea celei de-a doua metode. Eficienta si independenta sunt pentru prima metoda.
In practica, protocolul FTP se bazeaza foarte putin pe protocolul Telnet, asa ca prima metoda
nu implica o cantitate mare de cod.

3. FUNCTII PENTRU TRANSFERUL DE INFORMATII

Fisierele pot fi transmise doar prin conexiunea de date. Conexiunea de control este
folosita pentru transferul comenzilor, care descriu operatiile ce urmeaza sa fie executate,
si raspunsurile la aceste comenzi ( vezi sectiunea Raspunsuri la comenzi FTP ) . Exista
comenzi care se ocupa cu transferul informatiei intre host-uri. Printre acestea amintim aici
de comanda MODE care specifica felul in care bitii sunt transmisi, si comenzile STRUcture
si TYPE care sunt folosite pentru a defini modul in care este reprezentata informatia.
Transmiterea si reprezentarea sunt in mod normal independente dar transmisia de tip "Stream"
este dependenta de atributul structurii de fisiere si daca este folosita transmisia
"Compressed" tipul octetului de umplere depinde de tipul reprezentarii.

3.1. REPREZENTAREA INFORMATIEI SI STOCAREA EI

Informatia este transferata de pe un mediu de stocare de la un host catre un alt mediu
de stocare pe alt host. Uneori este necesara realizarea unor anumite transformari ale
informatiei deoarece reprezentarea informatiei pe cele doua sisteme de operare este diferita.
De exemplu, NVT-ASCII are o reprezentare diferita in sisteme diferite. Sistemele de tip DEC
TOPS-20 stocheaza fisierele in format NVT-ASCII sub forma de caractere ASCII de 7 biti,
aliniate la stanga in cuvinte de 36 de biti. Sistemele de tip IBM Mainframe stocheaza
fisierele folosind codificare EBCDIC pe 8 biti. Cele de tip Multics stocheaza fisierele
folosind NVT-ASCII sub forma a 4 caractere de cate 9 biti in cuvinte de 36 biti. Este
preferabila convertirea caracterelor in reprezentarea standard NVT-ASCII cand se transmite
text intre sisteme diferite. Host-urile care trimit si primesc vor trebui sa realizeze
transformarile necesare intre reprezentarea standard a caracterelor si cea interna.

O problema diferita apare in reprezentare cand se transmite informatie in format binar
( nu coduri de caracter ) intre host-uri diferite cu lungimi de cuvint diferite. Nu este
intotdeauna clar felul in care cel care trimite informatia face acest lucru si nici felul
in care in care cel care o primeste o stocheaza. De exemplu, cand se trimit octeti de 32
de biti de la sisteme care au reprezentarea interna pe cuvinte de 32 de biti, pe sisteme care
reprezinata datele pe cuvinte de 36 biti, ar fi preferabil ( din motive de eficienta si
utilitate ), ca informatia sa se pastreze sub forma de cuvinte de 32 biti aliniati la
dreapta in cuvinte de 36 biti in sistemele care primesc datele. In orice caz, utilizatorul
ar trebui sa aiba optiuni de specificare a formei de reprezentare a informatiei si functii
de transformare a formatului acesteia. Trebuie notat ca protocolul FTP permite reprezentari
limitate a informatiei.

Transformarile dorite in afara celor specificate trebuie facute de utilizator sau de
aplicatie direct.

3.1.1. TIPURI DE INFORMATIE

Reprezentarile informatiei sunt utilizate in protocolul FTP de catre utilizator prin
specificarea tipului. Acest tip poate defini implicit ( cazul ASCII sau EBCDIC) sau explicit
( cazul octetului Local ) o marime de interpretare care este interpretata ca "marime logica".
Trebuie observat ca aceasta nu are nimic in comun cu marimea octetului folosita pentru
transmiterea informatiei prin conexiunea de date, matine numita "marime de transfer", si cele
doua nu trebuie confundate. De exemplu NVT-ASCII are marimea logica de 8 biti. Daca tipul este
Local, atunci comanda TYPE are obligatoriu un al doilea parametru care specifica marimea
logica. Marimea de transfer este intotdeauna 8 bits.

3.1.1.1. TIPUL ASCII

Acest tip este cel implicit si trebuie sa fie acceptat de toate implementarile
protocolului. Este folosit in principal pentru transferul fisierelor de tip test, cu exceptia
cazului cand amblele host-uri gasesc tipul EBCDIC mai convenabil.

Host-ul care trimite informatia o converteste din reprezentarea interna in cea
standard NVT-ASCII pe 8 biti ( vezi specificatia protocolului Telnet). Host-ul care primeste
datele va converti din forma standard in reprezentarea sa interna.

In concordanta cu standardul NVT, secventa <CRLF> trebuie folosita unde este
necesara delimitarea unei linii de text. ( Vezi paragraful despre structura unui fisier de la
sfarsitul capitolului Reprezentarea informatiei si stocarea ei ).

Folosirea standardului NVT-ASCII inseamna ca informatia este encodata folosind
octeti de 8 biti.

Parametrii de formatare pentru ASCII si EBCDIC sunt discutati mai jos.

3.1.1.2. TIPUL EBCDIC

Acest tip de reprezentare a informatiei este util pentru un transfer eficient intre
host-uri ce folosesc EBCDIC pentru reprezenatarea interna a datelor.

Pentru transmiteren, informatia este reprezentata sub forma de caractere de 8 biti
codate EBCDIC. Codurile caracterelor sunt singura diferenta intre specificatiile functionale
dintre EBCDIC si ASCII.

Sfarsitul de linie ( diferit de sfarsitul de inregistrare , vezi paragraful despre
structura ) va fi probabil rar folosit cu tipul EBCDIC pentru al caracteriza structura, dar
unde este necesar caracterul <NL> va fi folosit.

3.1.1.3. TIPUL IMAGE

Informatia este trimisa ca o succesiune de biti care, pentru transfer, sunt grupati
in pachete de cate 8 biti( octeti ). Host-ul care primeste informatia trebuie sa o stocheze la
fel, ca o succesiune continua de biti. Structura sistemului pe care se pastreaza datele poate
necesita convertirea fisierelor in structuri conveniente ( octeti, cuvinte sau blocuri ).
Aceasta convertire se face cu completare de zerouri ( biti cu valoarea 0 ) la sfarsitul
fisierelor ( sau la sfarsitul fiecarei inregistrari ) si trebuie sa existe o metoda de
identificare a acestor biti astfel incat acestia sa poata fi inlocuiti cand fisierul este
transferat in intregime. Informatia adaugata trebuie sa sa fie cunoscuta bine pentru a permite
utilizatorului sa proceseze fisierele in locul in care acestea sunt stocate.

Tipul IMAGE este folosit pentru stocarea eficienta si pentru transferul informatiei
in format binar. Este recomandat ca acest tip sa fie acceptat de catre toate implementarile
protocolului FTP.

3.1.1.4. TIPUL LOCAL

Infomatia este transferata in octeti logici, a caror marime este specificata prin
al doilea parametru. Valoarea marimii octetului trebuie sa fie un numar zecimal; nu exista o
valoare implicita pentru marime. Marimea logica a octetului nu trebuie sa fie in mod necesar
aceeasi cu cea a octetului de transfer. Daca cele doua marimi sunt diferite, atunci octetii
logici trebuie sa fie grupati continuu, nelaundu-se in consideratie limitele octetilor si
cu completarea necesara la sfarsit.
Cand informatia ajunge la host-ul destinatie, aceasta va fi transformata intr-un
format dependent de marimea logica a octetilor si de host-ul gazda. Acest proces de
transformare trebuie sa fie inversabil ( un fiser identic poate fi tranferat daca sunt
folositi aceeasi parametri ) si trebuie sa fie facut cunoscut acest lucru de catre
implementatori.

De exemplu, sa presupunem un client FTP trimite numere in virgula mobila scrise
pe 36 de biti catre un host care stocheaza datele in cuvinte de 32 biti ar putea trimite
informatia sub forma de octeti locali cu marimea logica de 36. Host-ul care primeste trebuie
sa stocheze octetii logici astfel incat acestia sa poata fi usor manipulati; in acest exemplu
punand octetii logici de 36 biti in cuvinte de 64 biti ar trebui sa fie eficient si ar
rezolva problema.

In alt exemplu, o pereche de host-uri care pastreaza informatia in cuvinte de 36
biti pot schimba date intre ele folosind argumentul TYPE L 36. Informatia va fi trimisa in
octeti de 8 biti astfel 9 octeti ar rezolva problema.

3.1.1.5. CONTROLUL FORMATULUI

Tipurile ASCII si EBCDIC primesc de asemenea un al doilea parametru ( optional );
acesta indica ce fel de control vertical al formatului ( daca exista ) este asociat cu
fisierul respectiv. Urmatoarele tipuri de reprezentare a datelor sunt definite in FTP:

Un fisier de tip caracter este transferat catre un host din unul din aceste
trei motive: pentru tiparire, pentru stocare ( si mai tarziu copiere inapoi ) sau pentru
procesare. Daca un fisier este transferat pentru tiparire hostul care primeste fisierul
trebuie sa cunoasca cum este reprezentat controlul vertical al formatului. In cel de-al
doilea caz este posibil ca fisierul sa fie stocat si apoi transferat inapoi de la acel host
in aceeasi stare. In cel de-al treilea caz fisierul poate fi mutat de la un host la altul
pentru a fi procesat. Simplul format ASCII sau EBCDIC nu este de ajuns pentru a realiza
toate aceste lucruri. De aceea aceste tipuri au un al doilea parametru care specifica unul
din urmatoarele trei formate:

3.1.1.5.1. NON PRINT

Acesta este formatul implicita care este folosit daca al doilea parametru
este omis. Fomratul non-print trebuie sa fie acceptat de toate implementarile protocolului FTP.

Fisierul nu trebuie sa contina informatii despre formatarea verticala. Daca
este trimis unui proces de tiparire, acest proces poate sa foloseasca valori standard pentru
spatiere si margini.
In mod normal, acest format va fi folosit pentru fisiere destinate procesarii
sau stocarii.

3.1.1.5.2. Controale pentru formatare ale protocolului Telnet

Fisierul contine ASCII/EBCDIC controale pentru formatare verticala (i.e.,
<CR>, <LF>, <NL>, <VT>, <FF>) pe care procesul de tiparire le
va interpreta corespunzator. Secventa <CRLF>, in aceasta ordine, semnifica sfarsitul
de linie (EOF).

3.1.1.5.2. CARRIAGE CONTROL (ASA)

Fisierul contine caractere pentru formatare verticala ASA(FORTRAN). (Vezi
RFC 740 Appendix C; and Communicationsof the ACM, Vol. 7, No. 10, p. 606, Octombrie 1964.)
Intr-un fisier formatat in linii sau in inregistrari dupa standardul ASA, primul caracter nu
este tiparit. El este folosit pentru a determina miscarea verticala a hartiei care trebuie
sa se execute inainte ca restul inregistrarii sa fie tiparite.
Standardul ASA specifica urmatoarele caractere de control:

Character Spatierea verticala

blank muta foaia mai sus cu o linie
0 muta foaia mai sus cu doua linii
1 muta foaia deasupra urmatoarei foi
+ nu muta foaia , i.e., tipareste deasupra

In mod necesar trebuie sa existe o cale prin care un proces de tiparire sa
poata distinge sfarsitul unei entitati structurale. Intr-un fisier care este structurat
in inregistrari nu este nici o problema; inregistrarile vor fi marcate explicit in timpul
transferului sau stocarii. Daca fisierul nu are structura cu inregistrari, secventa de
sfarsit de linie <CRLF> este folosita pentru a separa liniile pentru tiparire, dar
aceste secvente sunt suprascrise de controalele ASA.

3.1.2. STRUCTURI DE DATE

Pentru a putea diferentia diferitele tipuri de reprezentare a datelor, protocolul
FTP permite specificarea structurii unui fisier. Exista trei tipuri de structuri de fisier
definite in FTP:

strcutura-fisier(file-structure)
nu este specificata nici o structura interna si fisierul
este considerat o secventa continua de octeti

structura cu inregistrari(record-structure)
fisierul este structurat secvential din inregistrari

structura cu pagini(page-structure)
where the file is made up of independent indexed pages.

Implicit tipul structurii unui fisier este primul tip ( structura-fisier) daca nu
a fost folosita comanda STRucture, dar tipurile de structura fisier si cu inregistrari
trebuie sa fie acceptate pentru fisierele text ( de exemplu fisierele cu tipul ASCII
sau EBCDIC) de toate implementarile protocolului FTP. Strcutura fisierului afecteaza atat
modul de transfer al unui fisier( vezi paragraful destinat metodelor de transfer), cat si
interpretarea si stocarea acelui fisier.
Structura "naturala" a unui fisier depinde de tipul de stocare a datelor de
catre un host. Un fisier cu cod sursa va fi memorat pe un host IBM mainframe sub forma
de inregistrari de lungime fixa dar pe un host DEC TOP-20 va fi memorat ca un sir de
caractere partitionat in linii, separate de exemplu de secventa <CRLF>. Daca
transferul fisierelor intre astfel de hostu-uri diferite este util, atunci inseamna ca
trebuie sa fie o metoda prin care un host intelege tipul in care este structurat fisierul.

Cum unele site-uri sunt orientate fisier iar altele orientate pe inregistrari,
ar putea aparea probleme in cazul in care un fisier cu o anumita structura este transferat
catre alt host. Daca un fisier cu o structura cu inregistrari este trimis catre un host care
are o strcutura de tip fisier, atunci host-ul care trimite fisierul ar trebui sa transforme
intern fisierul intr-o forma bazata pe inregistrari.
Evident, aceasta transformare este folositoare insa acest proces trebuie sa fie
reversibil, adica un fisier identic poate fi primit folosind o structura de tip inregistrare.

In cazul in care fisierul este trimis cu structura de tip fisier catre un host
care foloseste structura cu inregistrari, se pune problema impartirii acelui fisier in
inregistrari care sa poata fi procesate local. Daca aceasta impartire este necesara, atunci
implementarea FTP folosita trebuie foloseasca ca delimitator de linie secventa <CRLF>
pentru fisiere text codate ASCII sau <NL> pentru cele codate EBCDIC. Daca o
implementare FTP foloseste aceasta tehnica, atunci aceasta trebuie sa poata realiza si
transformarea inversa in cazul in care fisierul este primit cu structura de tip fisier.

3.1.2.1. STRUCTURA FISIER

Structura fisier este cea implicita in cazul in care nu este folosita comanda
STRucture.
In cazul in care este folosita acest tip de structura, fisierul este considerat
ca fiind o secventa continua de octeti.

3.1.2.2. STRUCTURA CU INREGISTRARI

Structura cu inregistrari folosita pentru fisierele de tip text ( ex. fisierele
al caror TYPE este ASCII sau EBCDIC) trebuie acceptata de toate implementarile FTP. Un fisier
este format in acest caz din inregistrari secventiale.

3.1.2.3. STRUCTURA CU PAGINI

Pentru a transfera fisiere care sunt discontinue, protocolul FTP defineste o
structura formata din pagini. Fisierele de acest tip sunt cunoscute ca fisiere cu acces
aletor("random access files") sau chiar sub numele de fisiere cu gauri("holey files"). In
aceste fisiere exista informatie suplimentara asociata cu intregul fisier(ex. desciptorul
de fiser), sau cu sectiuni din fisier (ex. controale pentru acces la diferite pagini),
sau informatii asociate cu amandoua. Aceste sectiuni de fisier se numesc pagini.

Pentru ca aceasta structura sa poata fi folosita cu pagini de marimi diferite
si informatii diferite, fiecare pagina este transferata impreuna cu un antet de pagina.
Acesta contine urmatoarele campuri:

Lungimea antetului (Header Length)
Reprezinta numarul de octeti logici din antetul paginii inclusiv acest
octet. Lungimea minima a antetului este 4.

Indexul paginii (Page Index)
Numarul de ordine al paginii din aceasta sectiune din fisier. Acesta nu
este numarul de transmitere al paginii, dar este indexul folosit pentru
identificarea paginii in fisier.

Lungimea informatiei (Data Length)
Numarul de octeti logici care formeaza informatia paginii. Minimul pentru
acest camp este 0.

Tipul paginii (Page Type)

Numar care reprezinta tipul paginii. Sunt definite urmatoarele tipuri:
0 = Ultima pagina (Last Page)

Acest numar indica sfarsitul unei transmisii paginate. Lungimea
antetului acestei pagini trebuie sa aiba lungimea de 4 octeti si
lungimea informatiei trebuie sa fie 0.

1 = Pagina simpla (Simple Page)

Acesta este tipul normal pentru fisiere simple paginate, care
nu folosesc informatii de control asociate. Lungimea antetului
trebuie sa fie 4.

2 = Descriptor de pagina (Descriptor Page)

Acest tip este folosit pentru a transmite informatia descriptiva
pentru fisier ca o singura secventa.

3 = Pagina cu acces controlat (Access Controlled Page)

Acest tip include un camp aditional in antet pentru fisiere
paginate care au informatie suplimentara despre accesul
controlat la nivel de pagina. Lungimea antetului trebuie sa fie 5.

Campuri optionale

Alte campuri optionale pot fi folosite pentru a furniza informatii
pentru controlul paginii, de exemplu control de acces la pagina
respectiva.

Toate aceste campuri au marimea unui octet logic. Lungimea unui asemenea octet
este specificata de comanda TYPE. Vezi Apppendix 1 si sectiunea dedicata acestei
comenzi pentru informatii suplimentare.

Trebuie tinut cont la setarea acestor parametri de urmatoarele lucruri: un fisier
trebuie sa fie stocat si trimis cu aceeasi parametri daca versiunea trebuie sa fie identica
cu cea transmisa original. Invers, implementarile FTP trebuie sa returneze un fisier
identic cu originalul daca paramtetrii folositi la stocare si primire sunt aceeasi.

3.2. REALIZAREA CONEXIUNILOR DE DATE

Mecanica transferului de informatii consta in realizarea conexiunii de date la
porturile corespunzatoare si alegerea parametrilor de transfer. Atat procesul DTP client
cat si cel server au un port implicit. Portul procesului client este acelasi port cu cel
al conexiunii de control (ex. U). Portul implicit al procesului server este portul
adiacent portului corespunzator conexiunii de control (ex. L-1).

Marimea unui octet de transfer este de 8 biti. Aceasta marime este valabila
pentru transferul de informatii; nu are nici o legatura cu reprezentarea informatiilor
in sistemul de fisiere al gazdei.

Procesul de transfer pasiv( poate fi sau un proces DTP client sau un proces
DTP server secundar) trebuie sa asculte portul de transfer pentru a putea transmite
o comanda de cerere. Comanda FTP de cerere determina directia transferului de date.
Procesul server, dupa ce primeste cererea de transfer, va initia conexiunea de date
la portul respectiv. Odata conexiunea stabilita, transferul de informatii poate incepe
intre procesele DTP, si interpretorul protocolului pe partea de server trimite o
confirmare interpretorului pe partea de client.

Implementarile FTP trebuie sa suporte folosirea porturilor implicite, si doar
interpretorul protocolului pe partea de client poate sa solicite schimbarea portului
intr-unul diferit de cel implicit.

Este posibil procesul client sa specifice un port alternativ prin comanda PORT.
Acelasi proces poate tipari un fisier la o imprimanta a unui TAC sau poate sa il
primeasca de la un al treilea host. In cel de-al doilea caz, interpretorul protocolului
pe partea de client realizeaza conexiunile de control cu amandoua interpretoarele de pe
partea de sever. Un server primeste o comanda pentru a asculta portul pentru o viitoare
conexiune. Interpretorul protocolului pe partea de client trimite unui interpretor de
pe partea de sever comanda PORT pentru a indica portul de transfer. In final, celor doua
procese server li se vor trimite comenzi corespunzatoare. Secventa exacta de comenzi
si raspunsuri la comenzi trimise intre controller-ul de pe partea de client si servere,
este definit in sectiunea de Raspunsuri FTP.

In general procesul server este responsabil cu mentinerea conexiunii de date -
initierea ei si inchiderea ei. Exceptie la acest lucru este atunci cand procesul client
DTP trimite informatia intr-un mod de transfer care necesita inchiderea conexiunii
pentru a indica EOF. Serverul trebuie sa inchida conexiunea in urmatoarele conditii:

1. Procesul server a terminat de trimis informatiile intr-un mod de transfer care
necesita o inchidere a conexiunii pentru a indica EOF.

2. Procesul server primeste o comanda ABORT de la procesul client.

3. Portul de transfer este schimbat cu o comanda de procesul client.

4. Conexiunea de control este inchisa in mod normanl sau altfel.

5. A aparut o eroare nerecuperabila.

Altfel inchiderea este o optiune a serverului, prin care acesta trebuie sa indice
acest lucru clientului cu un raspuns de tip 250 sau 226.

3.3. MANAGEMENTUL CONEXIUNII DE DATE

Proturile implicite ale conexiunii de date: toate implementarile trebuie sa suporte
folosirea porturilor implicite, si numai interpretorul protocolului pe partea de client
poate sa ceara folosirea unor alte porturi decat cele implicite.

Setarea altor porturi decat cele implicite: interpretorul protocolului pe partea
de client poate specifica alt port cu ajutorul comenzii PORT. Acelasi interpretor poate
cere procesului server sa identifice un alt port cu ajutorul comenzii PASV. O conexuine
fiind definita de o pereche de adrese, una din aceste actiuni este de ajuns pentru a
realiza o alta conexiune de date, desi este permis folosirea ambelor comenzi pentru
folosirea unor noi porturi.

Reutilizarea conexiunii de date: cand este folosit modul de transfer sub forma unui
flux, sfarsitul de fisier trebuie indicat prin inchiderea conexiunii. Acest lucru produce
o eroare daca sunt mai multe fisiere de transferat in acea sesiune, din cauza faptului
ca protocolul TCP trebuie sa mentina conexiunea un anumit timp pentru comunicatii stabile.
Astfel conexiunea nu poate fi redeschisa.

Exista doua solutii la aceasta problema. Prima este de a negocia un port ne-implicit.
A doua este folosirea unui alt mod de transfer.

Un mic comentariu la modurile de transfer: modul de transfer sub forma unui flux
este in mod inerent instabila, din moment ce nu se poate stabili daca conexiunea s-a inchis
prematur sau in mod normal. Celelalte tipuri de transfer( tip block, comprimat ) nu inchid
conexiunea pentru a indica sfarsitul de fisier. Aceste tipuri au codare FTP destula
folosita pentru a parcurgerea conexiunii de date si pentru determinarea sfarstiului de
fisier. Astfel, folosind aceste moduri, se poate lasa conexiunea deschisa pentru transferul
mai multor fisiere.

3.4. TIPURI DE TRANSFER

Urmatorul lucru care se discuta in continuare este alegerea tipului transferului. Exista
trei tipuri: unul care formateaza informatia si permite proceduri de restart; unul care
coprima de asemenea informatia pentru un transfer eficient; si unul care nu comprima deloc
informatia sau o face prea putin. Ultimul tip interactioneaza cu atributul care defineste
structura pentru a determina tipul procesarii. In modul comprimat, tipul reprezantarii
determina tipul octetului de transfer.

Toate modurile de transfer trebuie terminate cu o secventa EOF, lucru care poate fi
specificat explicit sau implicit prin inchiderea conexiunii de date. Pentru fisiere cu o
structura cu inregistrari, toate marcajele EOR(sfarsit de inregistrare) sunt explicite,
inclusiv cel final. Pentru fisierele cu structura de tip pagina este folosit un tip care
indica ultima pagina.

NOTE: In aceasta sectiune ne vom referi la octetul de transfer cu octet( fara a
specifica explicit acest lucru decat atunci cand este nevoie). In scopul de a standardiza
transferul, host-ul care trimite datele le va tranforma secventa interna care noteaza sfarsitul
de linie sau de inregistrare in reperzentarea standard descrisa de modul de transfer si
structura fisierului, si host-ul care primeste va realiza operatiile inverse, transformand
acestea in notatia sa interna. O inregistrare de pe o masina IBM Mainframe nu va fi
recunoscuta de o alta masina, deci secventa care descrie sfarsitul de inregistrare va fi
transferata ca un cod de control format din doi octeti in modul de transfer flux sau ca un
bit indicator in modul Block sau Comprimat. Specificatorul EOF intr-un fisier ASCII sau
EBCDIC fara structura de inregistrari trebuie indicat de secventa <CRLF> sau de
<NL>. Deoarece aceste transformari implica calcule suplimentare pentru unele masini,
sistemele de fisiere care folosesc aceeasi reprezentare interna care transfera fisiere
text doresc sa utilizeze reprezentarea binara sau modul de transfer de tip flux.
Urmatoarele tipuri de transfer a informatiei sunt definite in protocolul FTP:

3.4.1. MODUL FLUX DE CARACTERE

Informatia este transmisa ca un flux de octeti. Nu exista nici o restrictie in
tipul de reprezentare folosit; sunt permise structuri sub fomra de inregistrari.

Intr-un fisier structurat EOR si EOF vor fi indicate fiecare de un cod format
din 2 octeti. Primul octet din acest cod va fi intotdeauna caracterul escape. Al doilea
octet va avea ultimul bit setat 1 si restul 0 pentru EOR, iar pentru EOF penultimul
bit va fi setat pe 1 si restul 0; astfel octetul va avea valoarea 1 pentru EOR si 2
pentru EOF. EOR si EOF pot fi indicate impreuna in ultimul octet transmis prin setarea
utlimilor 2 biti (octetul va avea valoarea 3) . Daca un singur octet trebuie transferat,
el trebuie repetat in cel de-al doilea octet al codului de control.

Daca este folosita structura fisier, EOF este indicat prin inchiderea conexiunii
de catre host-ul care trimite si toti octetii sunt octeti de date.

3.4.2. MODUL BLOC (BLOCK)

Fisierul este trasnferat sub forma unor blocuri de date precedate de unul sau
mai multi octeti care formeaza antetul acestora. Antetul contine un numar si un cod
descriptor. Numarul reprezinta lungimea totala a blocului in octeti. El marcheaza si
inceputul unui nou bloc ( nu exista biti de umplere). Codul descriptor desemneaza: ultimul
block in fisier (si atunci este EOF acest cod), ultimul block din inregistrare (EOR),
marcator de restart (vezi sectiunea despre recuperarea dupa o eroare si restart) sau
date suspecte (datele care trebuie transferate sunt suspecte si nu sunt stabile). Acest
cod NU este folosit pentru controlul erorilor in FTP. Este motivat de faptul ca
host-urile pot schimba anumite tipuri de data (de exemplu date seismice sau despre vreme)
fara ca acestea sa fie corupte sau supuse unor erori interne (cum ar fi "erori la citirea
de pe banda magnetica"). Codul este folosit pentru a indica portiunile de date suspect.
Structurile sub forma de inregistrare sunt permise in acest mod, si orice alt tip de
reprezentare poate fi folosit.

Antetul consta in 3 octeti. Din cei 24 de biti ai acestuia, ultimii 16 reprezinta
numarul octetilor din blocul de date, iar urmatorii 8 reprezinta codul, dupa cum este
reprezentat mai jos.

Antetul unui bloc

+----------------+----------------+----------------+
| COD | CONTORUL OCTETILOR |
| 8 bits | 16 bits |
+----------------+----------------+----------------+

Codurile descriptive sunt indicate prin biti indicatori in octetul destinat
codului. Exista 4 coduri, fiecare fiind un numar zecimal corespunzator bitului respectiv
din cadrul octetului.

Cod Descriere

128 Sfarsitul blocului de date este EOR
64 Sfarsitul blocului de date este EOF
32 Erori suspectate in blocul de date
16 Blocul este un marcator al restartului

Cu acest sistem de codare, pot exista mai multe coduri pentru un singur bloc.
Pot exista mai multi biti indicatori, in functie de necesitati.

Marcatorul de restart este integrat in fluxul de date sub forma unui numar
intreg de octeti de 8 biti reprezentand caracterele printabile din limbajul folosit
pentru controlul conexiunii (implicit NVT-ASCII). <SP> (caracterul spatiu,
in limbajul corespunzator) nu trebuie folosit ca un marcator de resart.
De exemplu, pentru a transmite un marcator de 6 caractere, urmatoarea
secventa va fi trimisa:

+--------+--------+--------+
| Cod| Contorul octetilor |
|code= 16| = 6 |
+--------+--------+--------+

3.4.3. MODUL COMPRIMAT (COMPRESSED)

Exista 3 tipuri de informatie care poate transferata: date normale, trimise sub
forma de siruri de octeti; date comprimate, care constau in date reproduse sau de
umplere; sau informatie de control, trimisa sub forma unei secvente escape de 2 octeti.
Daca trebuie trimisi n octeti (0> n<127), atunci acesti n octeti sunt precedati
de un octet cu bitul cel mai din stanga setat pe 0 si cu restul de 7 biti continand
numarul n.

Sir de octeti:

1 7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n octeti---|
de date

Sirul de n octeti de date d(1),..., d(n) n trebuie sa fie un numar pozitiv.

Pentru a comprima un sir de n repetari ale octetului de date d, sunt trimisi
urmatorii 2 octeti:

Octet repetat:

2 6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0| n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

Un sir de n octeti de umplere pot fi comprimati intr-unul singur, unde octetul
de umplere variaza in functie de tipul reprezentarii informatiei. Daca tipul este ASCII
sau EBCDIC atunci octetul de umplere este <SP> (spatiu, cod ASCII 32, cod EBCDIC 64).
Daca tipul este IMAGE sau local atunci acest octet este octetul 0.

Sir de umplere::

2 6
+-+-+-+-+-+-+-+-+
|1 1| n |
+-+-+-+-+-+-+-+-+

Secventa escape este un dublu octet, din care primul este octetul escape
(numai biti 0) iar al doilea contine codurile descriptive definite in sectiunea modului
Bloc. Aceste coduri au aceesi insemnatate ca si in modul Bloc si se aplica la sirul de
octeti ce urmeaza.

Modul comprimat este folositor atunci cand se doreste obtinerea unei latimi
de banda mai mari in transmisia datelor in retele mari, cu o solicitare cat mai mica
a procesorului. Poate fi folosit efectiv la reducerea marimii unor fisiere prinatabile
cum ar fi cele generate de host-uri RJE.

3.5. RECUPERAREA DUPA ERORI SI RESTARTUL

Nu exista nici o masura impotriva pierderii bitilor sau a alterarii ordinii
acestora in timpul transferului informatiei; erorile la acest nivel sunt corectate
de protocolul TCP. Oricum, exista o procedura de restart pentru a proteja aplicatiile
client de eori de sistem majore (inclusiv probleme legate de host, de procesul FTP
sau de retea).

Procedura de restart este definita doar pentru modurile de transfer bloc si
comprimat. Acesta necesita ca aplicatia care trimite data sa insereze un cod special
de marcare in fluxul de date cu informatie speciala pentru marcare. Aceasta informatie
are insemnatate doar pentru aplicatia care trimite, si trebuie sa fie format din
caractere printabile in limbajul ales pentru conexiunea de control (ASCII sau EBCDIC).
Acest marcaj ar putea reprezenta numarul de biti, de inregistrari sau orice alta
informatie prin care un sistem poate identifica un punct de verificare. Aplicatia
care primeste data, daca implementeaza procedura de restart, va marca pozitia
corespunzatoare a acestui marcaj in sistemul care primeste, si va returna aceasta
informatie la aplicatia client.

In eventualitatea unei erori de sistem, aplicatia client poate restarta
transferul de informatie prin identificarea unui punct de marcaj cu procedura de
restart FTP. Urmatorul exemplu ilustreaza folosirea acestei proceduri.

Aplicatia care trimite informatia insereaza un bloc de marcaj specific in
fluxul de date la un anumit punct. Host-ul care primeste marcheaza acelasi punct
in sistemul sau de fisiere si transfera aplicatiei client ultimele marcaje de trimitere
si primire a datelor, direct sau prin conexiunea de control intr-un raspuns 110 (depinde
de cine este cel care trimite datele). In eventualitatea unei erori de sistem,
utilizatorul sau procesul care controleaza transferul restarteaza procesul server la
ultimul marcaj al serverului prin trimiterea unei comenzi restart cu numarul codului
de marcaj ca argument. Comanda restart este transmisa prin conexiunea de control si
este urmata imediat de comanda (cum ar fi RETR, STOR sau LIST) care era executata
cand a aparut eroarea de sistem.

4. FUNCTIILE PENTRU TRANSFERUL DE FISIERE

Canalul de comunicatie de la interpretorul de protocol al aplicatiei client catre
interpretorul de protocol al aplicatiei server este stabilit ca o conexiune TCP de la
aplicatia client catre portul standard al aplicatiei server. Interpretorul de protocol
al aplicatiei client este responsabil pentru transmiterea comenzilor FTP si interpretarea
raspunsurilor primite; interpretorul de protocol al aplicatiei server interpreteaza comenzii,
trimite raspunsuri si directioneaza DTP-urile sale pentru a realiza conexiunea si a transfera
datele. Daca a doua parte a transferului de date (procesul de transfer pasiv) este procesul
de transfer de date al aplicatiei client, atunci el este manipulat prin intermediul protocolului
intern al gazedei procesului de transfer de date al aplicatiei client; daca este un proces
secundar de transfer al datelor al aplicatiei server, atunci este manipulat prin intermediul
interpretorului propriu de protocol la cererea interpretorului de protocol al aplicatiei
client. Raspunsurile FTP sunt discutate in sectiunea urmatoare. In descrierea catorva comenzi
din aceasta sectiune, este de ajutor sa fim expliciti cu privire la posibilitatile de raspuns.

4.1. COMENZI FTP

4.1.1. COMENZI PENTRU CONTROLUL ACCESULUI

Urmatoarele comenzi specifica identificatorii pentru controlul accesului (codul comenzilor
este specificat intre paranteze).

USER NAME (USER)

Argumentul comenzii este un sir de caractere al aplicatiei Telnet ce identifica
utilizatorul. Identificarea utilizatorului este ceea ce cere aplicatia server pentru
a permite accesarea fisierelor sale. Aceasta comanda va fi in mod normal prima
transmisa de catre aplicatia client dupa ce conexiunile de control sunt realizate
(unele aplicatii server ar putea cere acestlucru). Informatii aditionale de identificare
sub forma unei parole sau/si a unui cont pot de asemenea sa fie cerute de unele aplicatii
server. Aplicatiile server pot permite ca o noua comanda de tipul USER sa fie introdusa
in orce moment pentru a shimba controlul accesului sau/si a inregistra noi informatii.
Acest lucru are efectul de eliberare a oricarui utilizator, parola si inregistrare de
informatii deja initiate si inceperea unei noi secvente de conectare. Toti parametrii
de transfer raman neshimbati si orice transfer de fisiere in desfasurare este terminat
sub vechii parametrii de control ai accesului.

PASSWORD (PASS)

Argumentul este un sir de caractere de tip Telnet care specifica parola
utilizatorului. Aceasta comanda trebuie neaparat precedata de comanda pentru
introducerea utilizatorului, si pentru unele site-uri, completeaza procesul
de identificare a utilizatorului pentru a permite accesul. Deoarece parola
este o informatie confidentiala este de dorit, in general, sa fie mascata
sau sa fie reprezentata cu un caracter special. Se pare ca aplicatia server
nu are nici o modalitate pe deplin sigura pentru a indeplini aceasta sarcina.
De aceea cade in responsabilitatea utilizatorului procesului FTP sa ascunda
informatia confidentiala a parolei.

CONT (ACCT)

Argumentul este un sir de caractere de tip Telnet care identifica contul
utilizatorului. Comanda nu este in mod necesar inrudita cu comanda USER,
astfel incat unele site-uri pot cere un cont pentru conectare si alte conturi
pentru un acces anume, cum ar fi stocarea fisierelor. In cazul din urma comanda
poate aparea in orice moment.

Exista coduri de raspuns la comanda pentru a diferentia aceste cazuri de
cele automatizate: cand sunt cerute informatii despre cont pentru conectare,
codul de raspuns la introducerea unei parole corecte este 332. Pe de alta parte,
daca nu sunt cerute informatii despre cont pentru conectare, codul de raspuns la
introducerea unei parole corecte este 230; si daca este nevoie de informatiile
despre cont mai tarziu intr-o comanda aparuta intr-un dialog, serverul ar trebui
sa returneze un cod de raspuns 332 sau 532 in functie de actiunea pe care o face:
stocheaza sau descarca comanda.

SCHIMBAREA DIRECTORULUI DE LUCRU (CWD)

Aceasta comanda permite utilizatorului sa lucreze cu un director sau set de date
diferit pentru stocarea fisierelor sau regasirea lor fara sa-si schimbe conexiunea
sau informatiile despre cont. Argumentul este o cale ce specifica un director sau
un alt indicator catre un grup de fisiere.

SCHIMBAREA DIRECTORULUI CATRE DIRECTORUL PARINTE (CDUP)

Aceasta comanda este un caz particular al comenzii CWD, si a fost inclusa pentru a
simplifica implementarea programelor in cazul transferarii arborilor de directoare
intre sisteme de operare avand sintaxe diferite pentru denumirea directorului parinte.
Codul de raspuns trbuie sa fie identic cu cel al comenzii CWD. Vezi Anexa 2 pentru
mai multe informatii.

STRUCTURA MOUNT (SMNT)

Aceasta comanda permite utilizatorului sa monteze un sistem de fisiere cu structura
diferita fara sa-si modifice conexiunea sau informatiile despre cont. Parametrii de
transfer raman neschimbati. Argumentul este o cale ce specifica un director sau
un alt indicator catre un grup de fisiere.

REINITIALIZEAZA (REIN)

Aceasata comanda termina un USER, golind toate intrarile si iesirile sale si informatiile
despre cont, exceptand transferurile in curs de desfasurare a caror terminare este asteptata.
Toti parametrii sunt resetati la cei impliciti si contolul conexiunii este lasat deschis.
Aceasta este identica cu starea in care un utilizator se gaseste imediat dupa ce conexiunea
a fost deschisa. O comanda de tipul USER este asteptata in continuare.

DECONECTAREA (QUIT)

Aceasta comanda termina un utilizator si daca daca nici un transfer de fisiere nu
este in desfasurare, serverul inchide conexiunea. Daca un transfer de fisiere este
in desfasurare, conexiunea va ramane deschisa pana i se va returna un raspuns de
terminare dupa care serverul o va inchide. Daca procesul utilizatorului transfera
fisiere pentru cativa utilizatori dar nu vrea sa se termine si deschide apoi conexiuni
pentru fiecare, atunci comand REIN ar trebui utilizata in locul comenzii QUIT.

O comanda neasteptata de inchidere a conexiunii va determina serverul sa efectueze o
actiune de intrerupere (ABOR) si de inchidere a conexiunii (QUIT).

4.1.2. COMENZILE PENTRU TRANSFERUL PARAMETRILOR

Toate datele ce se transfera ca parametrii au valori implicite, iar comenzile pentru
specificarea datelor ce se transfera ca parametrii sunt necesare doar daca valorile
implicite ale parametrilor sunt schimbate. Valoarea implicita este ultima valoare
specificata, sau daca nici o valoare nu a fost specificata, valoarea standrad implicita
este stabilita in acest caz. Aceasta implica ca serverul sa-si "aminteasca" vlorile
implicite aplicabile. Comenzile pot fi date in orice ordine exceptand faptul ca ele
trebuie sa preceada cererea serviciului FTP. Urmatoareale comenzi specifica datele
de transfer ale parametrilor:

PORTUL (PORT)

Argumentul este un PORT-GAZDA specificat ca port folosit in realizarea conexiunii de
date. Exista setari implicite pentru ambele porturi, ale clientului si ale serverului,
si in mod obisnuit nu este nevoie de aceasta comanda. Daca comanda este folosita
argumentul este rezultatul concatenarii dintre o adresa gazda pe 32-biti si o adresa
unui port TCP pe 16-biti. Aceasta adresa este separata in campuri de cate 8-biti si
evaluarea fiecarui camp este transmisa ca un numar zecimal(reprezentat ca sir de caractere).
Campurile sunt separate prin virgule. O comanda pentru port ar arata cam asa:

PORT h1,h2,h3,h4,p1,p2

unde h1 reprezinta cei mai semnificativi 8-biti ai adresei.

PASSIVE (PASV)

Aceasta comanda cere serverului DTP sa "asculte" la un port(care nu este portul sau
implicit) si sa astepte realizarea unei conexiuni decat sa initieze una in momentul
receptionarii unei comenzi de transfer. Raspunsul la aceasta comanda include adresele
gazdei si portul la care serverul asculta.

TIPUL REPREZENTARII (TYPE)

Argumentul specifica tipul reprezentarii asa cum este descris in Sectiunea despre
Reprezentarea si Stocarea Datelor. Cateva tipuri au un al doilea parametru. Primul
parametru este reprezentat de un singur caracter de tip Telnet, iar al dolilea parametru
este parametrul Format reprezentat in ASCII si EBCDIC; al doliea parametru pentru octetul
local este un intreg zecimal care indica dimensiunea in octeti. Parametrii sunt sparati
printr-un SP(spatiu, care are codul ASCII 32).

Urmatoarele coduri sunt asociate tipurilor:

I - Imagine

L ;dimensiunea in octeti;

Tipul implicit de reprezentare este ASCII neprintabil. Daca parametrul Format este schimbat,
iar mai tarziu daca doar primul argument este schimbat, Format revine la valoarea implicita
neprintabila.

STRUCTURA DE FISIERE (STRU)

Argumentul este codul unui singur caracter Telnet specificand structura de fisiere descrisa
in sectiunea Reprezentarea si Stocarea Datelor.

Urmatoarele coduri sunt asociate structurii de fisiere:

F - Fisier (nu structura de inregistrare)
R - Structura de inregistrare
P - Structura de pagina

Structura implicita este cea de Fisier.

MODUL DE TRANSFER (MODE)

Argumentul este codul unui singur caracter Telnet specificand modul de transfer al datelor
descris in sectiunea Moduri de Transmitere a Datelor.

Urmatoarele coduri sunt asociate modurilor de transmitere a datelor:

S - Flux
B - Bloc
C - Comprimat

Modul implicit de transfer este Flux.

4.1.3. COMENZILE SERVICIULUI FTP

Comenzile serviciului FTP descriu modul de transfer al fisierelor sau functiile sistemului
de fisiere cerute de utilizator. Argumentul unei comenzi a serviciului FTP este in mod
obisnuit o cale spre un fisier. Sintaxa unei cai trebuie sa corespunda conventiilor
serverului (cu standardele implicite aplicabile), si conventiilor de limbaj ale conexiunii.
Comportamentul implicit recomandat este acela de a folosi ultimul dispozitiv specificat,
director sau nume de fisier, sau cel standard definit implicit pentru utilizatorii locali.
Comenzile pot fi date in orice ordine, exceptie facand faptul ca o comanda "rename from"
trebuie urmata de o comanda "rename to" si comanda pentru repornire trebuie urmata de
comanda de intrerupere a serviciilor (de ex., STOR sau RETR). Datele, cand sunt transferate
ca raspuns la o comanda FTP, trebuie intotdeuna transmise prin conexiunea de date, cu
exceptia unor catorva raspunsuri informative. Urmatoarele comenzi specifica apelarea
unor servicii FTP:

SALVARE (RETR)

Aceasta comanda are ca efect transferul de catre serverul DTP a unei copii a fisierului,
specificat in calea data, de pe server-ul sau user-ul DTP la celalalt capat al conexiunii
de date. Starea si continutul fisierului de pe server nu trebuie sa fie afectate.

STOCARE (STOR)

Aceasta comanda determina serverul DTP sa accepte transferul de date prin intermediul
conexiunii de date si sa stocheze datele ca un fisier pe server. Daca fisierul specificat
in cale exista pe server, atunci continutul sau va fi inlocuit de catre datele care se
transfera. Un fisier nou va fi creat pe server daca fisierul specificat in cale nu exista
deja.

STOCARE UNICA (STOU)

Comanda are acelasi comportament ca si STOR cu exceptia faptului ca fisierul care rezulta
in urma transferului este creat in directorul curent cu un nume unic in acel director.
Raspunsul Transfer Initiat avand codul 250 trebuie sa includa si numele generat.

ADAUGARE (cu creare) (APPE)

Aceasta comanda determina serverul DTP sa accepte transferul de date prin intermediul
conexiunii si sa stocheze datele intr-un fisier pe server. Daca fisierul specificat in
cale exista deja pe server, atunci datele vor fi adaugate la fisier; altfel fisierul
specificat in cale va fi creat pe server.

ALOCARE (ALLO)

Comanda poate fi folosita de unele servere pentru a aloca suficienta memeorie pentru
a putea transfera fisierul. Argumentul va fi un intreg zecimal reprezentand numarul
de bytes (utilizand dimensiunea logica a unui byte) de memeorie rezervati pentru fisier.
Pentru fisiere transmise cu inregistrari sau structura de pagina o dimensiune maxima
a inregistrarii sau o dimensiune maxima a paginii este de asemenea necesara; aceasta
este indicat de un intreg zecimal in cel de-al doilea argument al comenzii.

Acest al doilea argument este optional, dar cand este prezent trbuie separat de primul
prin cele trei caractere Telnet: SP, R, SP. Aceasta comanda trebuie urmata de o comanda
STORe sau APPEnd. Comanda ALLO trebuie tratata ca un NOOP (nici o operatie) de acele
servere care nu cer ca dimensiunea maxima a fisierului sa fie declarata dinainte, si
acele servere interesate doar ca inregistrarea maxima sau dimensiunea maxima a paginii
sa accepte o valoare fictiva in primul argument si s-o ignore.

REPORNIRE (REST)

Argumentul reprezinta punctul din care servarul sa reporneasca transferul de fisiere.
Comanda nu determina transferul de fisiere prpriu-zis, ci se pozitioneaza in fisier
la pozitia de unde transferul a fost intrerupt. Ea va fi imediat urmata de comanda FTP
care va determina reluarea transferului.

REDENUMESTE DIN (RNFR)

Comanda specifica vechea cale a fisierului care se redenumeste. Ea trebuie neparat sa
fie urmata de o comnada "redenumeste la" specificand noua cale si noul nume.

REDENUMESTE LA (RNTO)

Comanda specifica noua cale si noul nume a fisierului specificat in comanda "redenumeste
din". Impreuna, cele doua comenzi redenumesc un fisier.

INTRERUPE (ABOR)

Comanda determina serverul sa intrerupa comanda FTP anterioara si orice transfer de
date asociat. Comanda de intrerupere poate necesita "actiuni speciale", discutate
in capitolul despre Comenzi FTP, pentru a forta recunoasterea ei de catre server.
Nu se va intampla nimic daca comanda antrioara a fost incheiata (incluzand transferul
de date). Conexiunea cu clientul nu va fi inchisa de catre server, dar conexiunea de
date va fi inchisa.

Exista doua stari in care se poate afla serverul la primirea acestei comenzi:
(1) comanda anterioara a fost incheiata, sau
(2) comanda anterioara se afla inca in desfasurare.

In primul caz, serverul inchide conexiunea de date (daca aceasta este deschisa)
si raspunde cu codul 226, indicand faptul ca comanda de intrerupre a fost executata
cu succes.

In cel de-al doilea caz, serverul intrerupe serviciul FTP in desfasurare si inchide
conexiunea de date, returnand codul 426 si indicand faptul ca serviciul solicitat
s-a terminat anormal. Severul transmite apoi codul 226, indicand faptul ca comanda
de intrerupere a fost executata cu succes.

STERGE (DELE)

Comanda sterge fisierul specificat in cale de pe server. Daca se doreste un nivel
mai avansat de securitate (cum ar fi o interogare, "Chiar doriti sa-l stergeti?"),
acestea trebuie precizate de procesul FTP client.

STERGE DIRECTOR (RMD)

Comanda are ca rezultat stergerea directorului specificat in cale ca director
(daca calea este absoluta) sau ca subdirector al directorului curent de lucru
(daca calea este relativa). Vezi Anexa II.

CREEAZA DIRECTOR (MKD)

Comanda are ca rezultat crearea directorului specificat in cale ca director
(daca calea este absoluta) sau ca subdirector al directorului curent de lucru
(daca calea este relativa). Vezi Anexa II.

OBTINE NUMELE DIRECTORULUI DE LUCRU (PWD)

Comanda returneaza numele directorului de lucru. Vezi Anexa II.

LISTEAZA (LIST)

Comanda determina transmiterea unei liste de la server la clientul DTP pasiv.
Daca calea specifica un director sau un alt grup de fisiere, serverul transfera
lista de fisiere a directorului specificat. Daca este specificat un fisier atunci
serverul transmite inforamtiile despre fisier. Un argument null implica directorul
curent al utilizatorului sau directorul implicit. Transferul de date se face prin
conexiunea de date in tipul ASCII sau EBCDIC. (Utilizatorul trebuie sa se asigure
daca tipul este corespunzator celui ASCII sau celui EBCDIC). Din moment ce informatiile
despre un fisier pot varia foarte mult de la un sisitem la altul, aceasta informatie
este dificil de folosit in mod automat intr-un program, dar poate fi destul de utila
unui programator uman.

LISTA DE NUME (NLST)

Comanda determina transmiterea unei liste a unui director catre un utilizator.
Calea trebuie sa specifice un director sau un alt descriptor pentru un grup de
fisire specific sistemului; un argument null determina folosirea directorului
curent. Serverul va returna numele fisierelor neinsotite de alte informatii.
Datele vor fi transferate sub format ASCII sau EBCDIC prin conexiunea de date
ca siruri de caractere valide separate prin CRLF sau NL. (Utilizatorul trebuie
sa se asigure din nou ca formatul transferului este corect.) Coamnda are drept
scop returnarea unor date pe care un program le va putea folosi pentru procesarea
viitoare a fisierelor. De exemplu, in implementarea unei functii de tipul
"transfer multiplu".

PARAMETRII DE POZITIE (SITE)

Comanda este folosita de server pentru a furniza servicii specifice sistemului
care sunt sunt esentiale pentru transferul de fisiere, dar nu intr-atat de
universale ca sa fie incluse ca si comenzi in protocol. Caracterul acestor servicii
si specificatiile sintaxei lor pot fi regasite ca raspuns la comanda HELP SITE.

SISTEM (SYST)

Comanda este folosita pentru a afla tipul sistemului de operare folosit de server.
Raspunsul are ca prim cuvant unul din numele sistemelor listate in versiunea
curenta a documentului de Atribuire a Numerelor[4].

STARE (STAT)

Comanda va determina transmiterea unui raspuns de stare prin conexiunea de control.
Comanda poate fi transmisa in timpul transferului de fisiere, caz in care serverul
va trimite drept raspuns starea operatiei in desfasurare, sau poate fi transmisa
intre transferurile de fisiere. In cazul din urma, comanda trebuie sa primeasca
un argument. Daca argumentul este o cale, comanda este analoaga cu comanda
"listeaza" exceptie facand faptul ca datele trebuie transferate prin intermediul
conexiunii de control. Daca este transmisa ca argument o parte a unei cai,
serverul va raspunde cu o lista de nume de fisiere sau atribute asociate cu
specificatia. Daca nu este transmis nici un argument, Serverul va returna
informatii despre starea generala a proceselor serverului FTP. Acestea vor
include valorile curente ale tuturor parametrilor de transfer si starea
conexiunilor.

ASISTENTA (HELP)

Comanda va determina serverul sa transmita utilizatorului informatii ajutatoare
cu privire la implementarile sale prin conexiunea de control. Comanda poate avea
un argument (ex., orice nume de comanda) si sa returneze informatii specifice
acestui argument. Raspunsul este unul din codurile 211 sau 214. Este recomandat
ca HELP sa fie permisa inainte de introducerea comenzii USER. Serverul poate
folosii aceste valori returnate pentru a specifica parametrii ce depind de el,
de ex., raspunsul la comanda HELP.

FARA OPERATII (NOOP)

Comanda nu afecteaza nici un parametru sau vreo comanda anterioara. Specifica ca
singura actiune transmiterea de catre server a unui raspuns de OK.

Protocolul pentru Transferul Fisierelor urmeaza specificatiile protocolului Telnet
pentru toate comunictiile prin conexiunea de control. Din moment ce limbajul folosit
pentru comunictiile Telnet poate fi o optiune discutatbila, toate referintele din
urmatoarele doua sectiuni vor fi la "limbajul Telnet" si similarului "cod Telnet".
In mod frecvent, vom intelege prin acestea NVT-ASCII si <CRLF>. Nici o alta
specificatie a protocolului Telnet nu va mai fi citata.

Comenzile FTP sunt "siruri de caractere Telnet" terminate cu "codul de sfarsit de
line Telnet". Codurile comenzilor sunt ele insele carctere alfabetice terminate de
caracterul SP (Spatiu) daca urmeaza parametrii si Telnet-EOL(End Of Line) altfel.
Codul comenzilor si semantica lor sunt descrise in aceasta sectiune; sintaxa detaliata
a comenzilor este specificata in sectiunea Comenzi, succesiunea raspunsurilor este
discutata in sectiunea Succesiunea Comenzilor si Raspunsurilor, si exemplele ilustrand
utilizarea comenzilor sunt descrise in sectiunea Utilizari Tipice FTP.

Comenzile FTP pot fi impartite in cele specificand indentificatorii pentru controlul
accesului, parametrii de transfer a datelor, sau cereri ale unor servicii FTP. Anumite
comenzi (cum ar fi ABOR, STAT, QUIT) pot fi transmise prin conexiunea de control in
timp ce se desfasoara un transfer de date. Este posibil ca unele servere sa nu fie
capabile sa monitorizeze conexiunea de control si conexiunea de date simultan,
caz in care unele actiuni speciale sunt necesare pentru a atrage atentia serverului.
Urmatoarea ordine este recomandata ca incercare:

1. Utilizatorul introduce semnalul Telenet "Proces Intrerupt" (IP)
in sirul Telnet.

2. Utilizatorul transmite semnalul Telnet "Synch"

3. Utilizatorul introduce comanda (de ex., ABOR) in sirul Telnet.

4. Serverul PI, dupa ce primeste "IP", scaneaza sirul Telnet pentru
a gasi exact ocomanda FTP.

(pentru alte servere acestea s-ar putea sa nu fie necesare, dar actiunile prezentate
mai sus nu vor avea un efect neobisnuit)

4.2. RASPUNSURILE FTP

Raspunsurile la comenzile FTP sunt concepute ca sa asigure sincronizarea cererilor
si actiunilor in procesul de transfer al fisierelor, si sa garanteze ca procesul
client stie starea serverului. Orice comanda trebuie sa genereze cel putin un raspuns,
chiar daca pot fi si mai multe; in cazul din urma, respunsurile multiple trebuie
distinse usor. In plus, unele comenzi se desfasoara in grupuri secventiale, cum ar fi
USER, PASS si ACCT, sau RNFR si RNTO. Raspunsurile arata existenta unei stari intermediare
daca toaste comenzile anterioare s-au incheiat cu succes. O eroare in orice punct al
secventei necesita repetarea intregii secvente de la inceput.

Detaliile despre raspunsurile la secventa de comenzi sunt explicitate
in setul de diagrame de mai jos.

Un raspuns FTP consta intr-un numar de trei cifre (transmis ca trei caractere alfanumerice)
urmat de un text. Numarul este dedicat utilizarii automate pentru a detremina starea
urmatoare; Textul este dedicat utilizatorului uman. Se doreste ca cele trei cifre sa
contina suficienta informatie codata astfel incat procesul utilizator nu are nevoie sa
analizeze textul si-l poate chiar descarca sau sa-l transmita unui alt utilizator, cat
mai potrivit. In particular, textul poate fi dependent de server, deci cel mai probabil
textul pentru fiecare cod de raspuns va varia.

Un raspuns contine un cod de 3 cifre, urmat de Spatiu SP, urmat de o linie de text
(lungimea maxima a unei linii fiind specificata), si terminat cu codul telnet pentru
sfarsit de linie. Oricum vor exista cazuri in care textul va fi mai lung decat o singura
linie. In aceste cazuri textul complet trebuie parantetizat astfel incat procesul client
cand sa se opresca din citirea raspunsului (de ex., sa se opreasaca din prelucrarea intarii
de la conexiunea de control) si sa faca altceva. Aceasta cere un format special al primei
linii pentru a indica ca urmeaza mai mult decat o linie, si unul pentru ultima linie pentru
a semnala ca este ultima. Cel putin una dintre acestea trebuie sa contina codul de raspuns
cel mai potrivit pentru a semnala starea tranzactiei. Pentru a satisface toate diferntele,
s-a hotarat ca ambele linii, cea de inceput si cea de sfarsit trbuie sa fie la fel.

Astfel, formatul pentru raspunsurile cu mai multe linii, prima linie va incepe cu codul de
raspuns, urmat de text. Ultima linie va incepe cu acelasi cod urmat imediat de spatiu SP,
un text optional si caracterul de sfarsit de linie Telnet.

De exemplu:
123-Prima linie
A doua linie
234 O linie care incepe cu numar
123 Ultima linie

Procesul client trebuie sa caute doar a doua aparitie a codului de raspuns, urmata de SP
(spatiu) la inceputul liniei, si sa ignore toate liniile intermediare. Daca o linie
intermediara incepe cu un numar de trei cifre, Serverul trebuie sa verifice inceputul
pentru a evita confuziile.

Aceasta schema permite rutinelor standard ale sistemului sa fie folosite pentru a returna
informatii (cum este raspunsul pentru STAT) cu prima si ultima linie respectand
conventia de mai sus atasate. In rare cazuri aceste rutine sunt capabile sa genereze trei
cifre si un spatiu la inceputul unei linii, inceputul fiecarei linii de text fiind partea
unui text neutru, cumar fi spatiul.

Aceasta schema presupune ca rspunsurile cu mai multe linii nu vor fi gresit interpretate.

Cele trei cifre ale unui raspuns au fiecare o semnificatie speciala. Scopul este de a
permite raspunsuri de la cele mai simple la cele mai sofisticate catre procesul client.
Prima cifra semnifica daca rspunsul este valid, invlid sau incomplet. Referindu-ne la
diagrama de stare, un proces client nesofisticat va fi capabil sa-si determine actiunea
viitoare examinand pur si simplu prima cifra. Un proces client care doreste sa stie
aproximativ ce tip de eroare s-a produs (de ex., eroare la sistemul de fisiere, eroare
de sintaxa a comenzii) poate examina a doua cifra, rezervandu-se a treia cifra pentru o
informare si mai precisa.

Exista cinci valori pentru prima cifra din codul de raspuns:

1 Raspuns Pozitiv Preliminar

Cererea a fost initiata; se asteapta un alt raspuns
inainte de a executa o noua comanda. (Procesul client
care trimite o alta comanda inainte de incheierea
raspunsului va probuce o violare a protocolului; dar
serverul FTP va pune in coada de comenzi orice comanda
primita in timpul executiei altei comenzi.) Acest tip
de raspuns poate fi folosit pentru a indica faptul ca
aceasta comanda a fost acceptata si procesul client
poate acorda atentie in continuare conexiunii de date,
pentru ca este dificila implementarea in acest caz a
unei monitorizari simultane. Serverul FTP va transmite
cel putin un raspuns din categoria 1 pentru o comanda.

2 Raspuns Pozitiv de Completare

Cerereaa fost indeplinita cu succes. O noua cerere poate
fi initiata.

3 Raspuns Pozitiv Intermediar

Comanda a fost acceptata, dar cererea este in asteptare,
asteptand informatii ulterioare. Utilizatorul trebuie sa
trimita o alta comanda care sa specifice aceasta informatie.
Acest raspuns se foloseste in grupurile de comenzi.

4 Raspuns Negativ Rapid de Terminare

Comanda nu a fost acceptata si actiunea solicitata nu a
avut loc, dar cauza erorii este tempoarara si actiunea
poate fi ceruta din nou. Utilizatorul trebuie sa se intoarca
la inceputul secventei de comenzi, daca exista. Este dificil
sa atribui lui transient un inteles, in particular cand doua
parti distincte (servarul si clientul) trebuie sa se puna de
acord cu interpretarea. Fiecare raspuns din cea de-a 4 categorie
trebuie sa aiba valori de timp putin diferite, dar scopul este ca
procesul client sa fie incurajat sa incerce din nou. O regula in
determinarea daca un raspuns este din a 4-a sau a 5-a categorie
(Negativ Permanent) este aceea ca un raspuns este in a 4-a
categorie daca comanda poate fi repetata fara nici o schimbare
in formulare sau in propietatile utilizatorului sau serverului
(ex., comanda este scrisa la fel si cu aceleasi argumente;
utilizatorul nu-si modifica fisierul de acces sau numele; serverul
nu-si schimba implementarea)

5 Raspuns Negativ Permanent de Terminare

Comanda nu a fost acceptata si actiunea nu s-a petrecut.
Procesul client este descurajat in a mai repeta comanda
exact in aceeasi forma (in aceeasi secventa). Chiar si
cateva cauze de erori permanente pot fi corectate, deci
utilizatorul uman trebuie sa-si directioneze procesul sau
client sa reinitieze secventa de comenzi print-o actiune
directa ulterioara (ex., dupa ce scrierea a fost schimbata,
sau clientul si-a modificat starea directorului)

Urmatoarele grupuri de functii sunt codate in cea de-a doua cifra:

x0 Sintaxa - Acest raspuns se refera la erorile de sintaxa, corecte
sintactic care nu se potrivesc nici unei categorii functionale,
neimplementate sau comenzile inutile.

x2 Informatia - Sunt replici care cer informatii, cum ar fi satrea sau
indicatii.

x3 Conexiuni - Raspunsuri care se refera la control sau conexiunea de date.

x4 Autentificare si inregistrare - raspunsuri pentru procesul de logare
si procedurile de inregistrare.

x4 Nespecificat pana in prezent.

x5 Sistemul de fisiere - Raspunsurile indica starea sistemului de fisiere
al serverului in legatura cu cererile de transfer sau alte sisteme
de fisiere.

A treia cifra da o gradatie mai fina in categoria de functii, specificata in cea de-a
doua cifra. Lista de raspunsuri de mai jos ilustreaza aceasta. De remarcat ca textul
asociat cu fiecare raspuns este recomandat, si mai putin cu caracter obligatoriu, si
se poate schimba potrivit comenzii cu care este asociat. Codurile de raspuns, pe de
alta parte, terbuie sa urmeze in mod strict specificatiile din ultima parte; adica,
implementarea serverului nu trebuie sa inventeze coduri noi pentru situatii care sunt
doar putin diferite de cele descrise aici, ci ar trebui sa adapteze codurile deja
definite.

O comanda ca TYPE sau ALLO a carei executie cu succes nu ofera procesului
client nici o informatie va cauza un raspuns cu codul 200. Daca comanda
nu este implementata de un proces particular al unui server FTP pentru ca
nu are relevanta pentru acel calculator, de exemplu ALLO pe un TOPS-20, un
raspuns pozitiv de terminare este cerut astfel incat procesul client sa
stie cand poate continua. Un rspuns 202 este folosit in acest caz cu, de
exemplu, textul: "Nu este necesara alocarea de memorie". Daca, pe de alta
parte, comanda cere o actiune care nu tine de cel apelat si nu este
implementata, raspunsul este 502. O imbunatatire pentru ceea ce este 504
pentru o comanda care este implementata, dar care cere un parametru
neimplementat.

4.2.1 Codurile de raspuns pentru grupurile de functii

200 Comanda OK.
500 Eroare de sintaxa, comanda nerecunoscuta.
Poate include si erori ca 'linia comenzii este prea lunga'.
501 Eroare de sintaxa in parametrii sau argumente.
202 Comanda neimplementata, inutila pentru program.
502 Comanda neimplementata.
503 Secventa gresita de comenzi.
504 Comanda neimplementata pentru acest parametru.
110 Raspuns care indica repornirea.
In acest caz, textul este exact si nu depinde de implementarile
particulare; trebuie citit:
MARK yyyy = mmmm
Unde yyyy fluxul este de date al procesului client, iar mmmm este
echivalentul acestuaia pe server.
211 Starea sistemului, sau o indicatie de la sistem.
212 Starea directorului.
213 Starea fisierului.
214 Mesaj cu explicatii.
Despre cum se utilizeaza serverul sau despre intelesul
unei comenzi nestandard. Comanda este utila doar utilizatorului
uman.
215 NUMELE tipului sistemului.
unde NUME este numele oficial al unui sistem din lista cu
Numerele Asociate.

120 Serviciu gata in nnn minute.
220 Serviciu disponibil pentru un nou utilizator.
221 Serviciul inchide conexiunea de control.
Deconectare.
421 Seviciul nu este disponibil, inchide conexiunea de control.
Acesta poate fi un raspuns la orice comanda daca serviciul
stie ca trebuie sa se inchida.
125 Conexiunea de date este deja stabilita; transfer inceput.
225 Conexiunea de date este deschisa; nici un transfer in desfasurare.
425 Nu pot deschide conexiunea de date.
226 Inchiderea conexiunii de date.
Actiunea ceruta pentru un fisier a fost executata cu succes (de ex.,
fisier in transfer sau fisier anulat)
426 Conexiune inchisa; transfer anulat.
227 Intrare in modul pasiv (h1,h2,h3,h4,p1,p2).

230 Utilizator conectat, continua.
530 Neconectat.
331 Numele utilizatorului este valid, introduceti parola.
332 Este nevoie de inregistrare pentru conectare.
532 Este nevoie de inregistrare pentru a memora fisiere.
150 Starea fisierului este buna; pe punctul de a deschide conexiunea de date.
250 Actiunea ceruta pentru fisier este OK, indeplinita.
257 "CALE" creata.
350 Actiunea ceruta pentru fisier asteapta informatii aditionale.
450 Actiunea ceruta pentru fisier neacceptata.
Fisier nedisponibil (de ex., fisier ocupat).
550 Actiunea ceruta pentru fisier neacceptata.
Fisier nedisponibil (de ex., fisierul nu este gasit, nu am acces).
451 Cerere anualta. Eroare locala in desfasurare.
551 Cerere anulata. Tip de pagina necunoscut.
452 Actiunea ceruta pentru fisier neacceptata.
Memorie insuficienta in sistem.
552 Actiunea ceruta pentru fisier anulata.
S-a depasit memoria alocata (pentru directorul curent sau
setul de date).
553 Actiunea ceruta pentru fisier neacceptata.
Nume de fisier nepermis.

4.2.2 Ordinea numerica a codurilor de raspuns

110 Raspuns care indica repornirea.
In acest caz, textul este exact si nu depinde de implementarile
particulare; trebuie citit:
MARK yyyy = mmmm
Unde yyyy este fluxul de date al procesului client, iar mmmm este
echivalentul acestuaia pe server.
120 Serviciu gata in nnn minute.
125 Conexiunea de date este deja stabilita; transfer inceput.
150 Starea fisierului este buna; pe punctul de a deschide conexiunea de date.
200 Comanda OK.
202 Comanda neimplementata, inutila pentru program.
211 Starea sistemului, sau o indicatie de la sistem.
212 Starea directorului.
213 Starea fisierului.
214 Mesaj cu explicatii.
Despre cum se utilizeaza serverul sau despre intelesul
unei comenzi nestandard. Comanda este utila doar utilizatorului
uman.
215 NUMELE tipului sistemului.
unde NUME este numele oficial al unui sistem din lista cu
Numerele Asociate.
220 Serviciu disponibil pentru un nou utilizator.
221 Serviciul inchide conexiunea de control.
Deconectare.
225 Conexiunea de date este deschisa; nici un transfer in desfasurare.
226 Inchiderea conexiunii de date.
Actiunea ceruta pentru un fisier a fost executata cu succes (de ex.,
fisier in transfer sau fisier anulat)
227 Intrare in modul pasiv (h1,h2,h3,h4,p1,p2).
230 Utilizator conectat, continua.
250 Actiunea ceruta pentru fisier este OK, indeplinita.
257 "CALE" creata.

331 Numele utilizatorului este valid, introduceti parola.
332 Este nevoie de inregistrare pentru conectare.
350 Actiunea ceruta pentru fisier asteapta informatii aditionale.

421 Seviciul nu este disponibil, inchide conexiunea de control.
Acesta poate fi un raspuns la orice comanda daca serviciul
stie ca trebuie sa se inchida.
425 Nu pot deschide conexiunea de date.
426 Conexiune inchisa; transfer anulat.

450 Actiunea ceruta pentru fisier neacceptata.
Fisier nedisponibil (de ex., fisier ocupat).
451 Cerere anualta. Eroare locala in desfasurare.
452 Actiunea ceruta pentru fisier neacceptata.
Memorie insuficienta in sistem.

500 Eroare de sintaxa, comanda nerecunoscuta.
Poate include si erori ca 'linia comenzii este prea lunga'.
501 Eroare de sintaxa in parametrii sau argumente.
502 Comanda neimplementata.
503 Secventa gresita de comenzi.
504 Comanda neimplementata pentru acest parametru.
530 Neconectat.
532 Este nevoie de inregistrare pentru a memora fisiere.
550 Actiunea ceruta pentru fisier neacceptata.
Fisier nedisponibil (de ex., fisierul nu este gasit, nu am acces).
551 Cerere anulata. Tip de pagina necunoscut.
552 Actiunea ceruta pentru fisier anulata.
S-a depasit memoria alocata (pentru directorul curent sau
setul de date).
553 Actiunea ceruta pentru fisier neacceptata.
Nume de fisier nepermis.

5. SPECIFICATII DECLARATIVE

5.1. IMPLEMENTARE MINIMA

In scopul de a realiza Servere FTP functionale fara mesaje de eroare
inutile, urmatoarea implementare minimala este ceruta pentru toate
serverele:

TIP - ASCII neprintabil
MOD - Flux
STRUCTURA - Fisier, Inregistrare
COMENZI - USER, QUIT, PORT,
TYPE, MODE, STRU,
pentru valorile implicite
RETR, STOR,
NOOP.

Valorile implicite pentru parametrii de transfer:

TIP - ASCII neprintabil
MOD - Flux
STRUCTURA - Fisier

Toate gazdele trebuie sa accepte cele mai de sus ca standarde implicite.

5.2. CONEXIUNI

Interpretorul de protocol al serverului va "asculta" la portul L. Clientul sau interpretorul
de protocol al clientului va initia conexiunea de control full-duplex. Procesele serverului
- si clientului - trebuie sa urmeze conventiile protocolului Telnet asa cum sunt specificate
in cartea ARPA-Inernet Protocol. Serverele nu sunt obligate sa se ingrijeasca de editarea
liniilor de comanda si pot cere ca aceasta sa se faca in gazda client. Conexiunea de control
va fi inchisa de catre server la cererea clientului dupa relizarea tuturor transferurilor.

Clientul DTP trebuie sa "asculte" la portul de date specificat: acesta poate fi portul client
implicit (U) sau un port specificat prin comanda PORT. Serverul va initia conexiunea de date
de la portul sau implicit (L-1) utilizand portul specificat de utilizator. Directia transferului
si portul folosit va fi determinat de serviciul de comenzi FTP.

Nu toate implementarile FTP suporta transferul de date utilizand portul implicit, si doar
clientul PI poate initia folosirea porturilor implicite.

Cand datele se transfera intre doua servere, A si B (figura 2), clientul PI, C, stabileste
conexiunile de control cu ambele servere PI. Unuia dintre servere, sa spunem A, ii este
transmisa o comanda PASV cere-i spune sa "asculte" la portul sau de date in loc sa initieze
o conxiune atunci cand primeste o comanda pentru initierea serviciului de transfer. Cand
clientul PI primeste comanda PASV, care include identitatea gazdei si portul care este ascultat,
clientul PI trimite apoi portul lui A lui B intr-o comanda PORT; o replica este returnata.
Clientul PI trimite apoi comenzile corespunzatoare serviciului la A si la B. Serverul B
initiaza conexiunea si incepe transferul. Secventa replicilor de raspuns este descrisa mai
jos unde mesajele sunt pe verticala sincrone, iar pe orizontala asincrone:

Client-PI - Server A User-PI - Server B
------------------ ------------------

C->A : Connect C->B : Connect
C->A : PASV
A->C : 227 Intrare in modul pasiv. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 OK
C->A : STOR C->B : RETR
B->A : Conectare la HOST-A, PORT-a

Figure 3

Conexiunea de date va fi inchisa de catre server in conditiile descrise in sectiunea despre
Stabilirea Conexiunilor de Date. Daca conexiunea de date este pe punctul de a fi inchisa in
urma unui trnsfer de date cand inchiderea conexiunii nu este ceruta pentru a marca sfarsitul
de fisier, serverul trbuie sa faca acest lucru imediat. Asteptand pana dupa ce o noua comanda
de transfer nu este permisa deoarece procesul client a testat deja conexiunea de date pentru
a vedea daca trbuie sa faca o "ascultare"; (clientul trebuie sa "asculte" la un port de date
inchis inainte sa trimita cererea de transfer). Pentru a preveni concurenta aici, serverul
trimite un raspuns 226 dupa inchiderea conexiuniui de date (sau daca conexiunea este lasata
deschisa, se transmite raspunsul "transfer de fisier incheiat" (250), si clientul PI trbuie
sa astepte una dintre acele replici inainte de a emite o noua comanda).

Oricand utilizatorul sau serverul vede conexiunea inchisa de cealalta parte, trebuie sa
citeasca prompt orice data ramasa in coada conexiunii si sa procedeze la inchiderea partii
sale a conexiunii.

5.3. COMENZI

Comenzile sunt siruri de caractere Telnet transmise prin conexiunea de control asa cum
s-a descris in sectiunea Comenzi FTP. Functiile si semantica comenzilor FTP sunt descrise
in sectiunile Comenzile pentru Controlul Accesului, Comenzile pentru Transferul Parametrilor,
Comenzile Serviciului FTP , Comenzi Amestecate. Sintaxa comenzii este specificata aici.
Astfel, oricare dintre urmatoarele poate fi comanda cautata:

Comenzile incep cu un cod de comanda urmate de un argument. Codurile comenzii sunt formate
din patru sau cinci caractere alfabetice. Majusculele si minusculele sunt tratate la fel.

RETR Retr retr ReTr rETr

Aceasta se aplica de asemenea oricaror simboluri reprezentand vlori de parametrii, cum ar fi
A sau a pentru tipul ASCII. Codurile comenzilor si argumentele sunt separate prin unul sau mai
multe spatii.

Argumentele consista dintr-un sir cu numar variabil de caractere terminat cu secventa de caractere
<CRLF> (Carriage Return, Line Feed) pentru reprezentarea ASCII; pentru alte limbaje se
foloseste un alt caracter care sa marcheze sfarsitul de linie. Serverul nu va intreprinde nici
o actiune pana cand nu va intalni caracterul de sfarsit de linie.

Sintaxa este specificata mai jos in caractere ASCII. Toate caracterele argumentelor sunt
caractere ASCII incluzand si reprezentarea zecimala a intregilor. Parantezele patrate
incadreaza un argument optional. Daca optiunea nu este considerata, valoarea implicita cea
mai apropiata este considerata.

5.3.1. COMENZI FTP

Uramtoarele sunt comenzi FTP:

USER <SP> <numele utilizatorului> <CRLF>
PASS <SP> <parola> <CRLF>
ACCT <SP> <informatii despre cont> <CRLF>
CWD <SP> <cale> <CRLF>
CDUP <CRLF>
SMNT <SP> <cale; <CRLF>
QUIT <CRLF>
REIN <CRLF>
PORT <SP> <portul gazdei> <CRLF>
PASV <CRLF>
TYPE <SP> <tipul codului;> <CRLF>
STRU <SP> <structura codului> <CRLF>
MODE <SP> <modul codeului> <CRLF>
RETR <SP> <cale> <CRLF>
STOR <SP> <cale> <CRLF>
STOU <CRLF>
APPE <SP> <cale> <CRLF>
ALLO <SP> <intreg-zecimal>
[<SP> R <SP> <intreg-zecimal>] <CRLF>
REST <SP> <semn> <CRLF>
RNFR <SP> <cale> <CRLF>
RNTO <SP> <cale> <CRLF>
ABOR <CRLF>
DELE <SP> <cale> <CRLF>
RMD <SP> <cale> <CRLF>
MKD <SP> <cale> <CRLF>
PWD <CRLF>
LIST [<SP> <cale>] <CRLF>
NLST [<SP> <cale>] <CRLF>
SITE <SP> <sir de caractere> <CRLF>
SYST <CRLF>
STAT [<SP> <cale>] <CRLF>
HELP [<SP> <sir de caractere>] <CRLF>
NOOP <CRLF>

5.3.2. ARGUMENTELE COMENZILOR FTP

Sintaxa argumentelor de mai sus (utilizand notatia BNF, unde este posibila) este:

<utilizator> ::= <sir de caractere>
<parola> ::= <sir de caractere>
<informatii despre cont> ::= <sir de caractere>
<sir de caractere> ::= <caracter>
| <caracter><sir de caractere>
<caracter> ::= oricare dintre cele 128 caractere ASCII exceptand <CR> si <LF>
<semn> ::= <sir de caractere printabil>
<sir de caractere printabil> ::= <caracter printabil>
| <caracter printabil><sir de caractere printabil>
<caracter printabil> ::= caractere printabile, orice cod ASCII intre 33 si 126

<dimensiunea byte-ului> ::= <numar>
<portul gazdei> ::= <numarul gazdei>,<numarul portului>
<numarul gazdei> ::= <numar>,<numar>,<numar;,<numar>
<numarul portului> ::= <numar>,<numar>
<number> ::= orice numar zecimal intreg intre 1 si 255
<forma codului> ::= N | T | C
<tipul codului> ::= A [<sp> <forma codului>]
| E [<sp> <forma codului>]
| I
| L <sp> <byte-size>
<structura codului> ::= F | R | P
<modul codului> ::= S | B | C
<calea> ::= <sir de caractere>
<intreg zecimal> ::= orice zecimal intreg

5.4. SECVENTE DE COMENZI SI REPLICI

Comunicatia dintre server si client se doreste a fi un dialog alternant. Astfel incat, clientul
emite o comanda FTP si serverul raspunde cu o replica. Clientul trebuie sa astepte pentru acest
raspuns initial, de succes sau esec, inainte de a transmite alte comenzi.

Unele comenzi cer un al doilea raspuns pentru care clientul va trebui de asemenea sa astepte.
Aceste replici pot replica, de exemplu, in legatura cu desfasurarea sau incheierea unui transfer
de fisiere sau inchiderea unei conexiuni de date. Sunt raspunsuri secundare la comenzile pentru
transferul de fisiere.

Un grup important de raspunsuri informationale este conexiunea de salut. In imprejurari normale,
un servar va trimite raspunsul 220, "astept intrare", cand conexiunea este stabilita. Clientul
trbuie sa astepte pentru acest mesaj de salut inainte de a trimite orice comanda. Daca serverul
nu poate primi nici o intrare intr-un moment, o replica 120 "interziere asteptata" este trimisa
imediat si un raspuns 220 cand este pregatit. Clientul va stii sa nu se blocheze daca este o
intarziere.

Replici spontane

Uneori "sistemul" transmite in mod spontan un mesaj la client. De exemplu, "Sistemul se va
inchide in 15 minute". Nu sunt reactii in FTP pentru asemenea mesaje spontane trimise clientului
de catre server. Este recomandat ca astfel de informatii sa fie puse in coada de asteptare a
serverului PI si trimise clientului PI in raspunsul urmator (posibil intr-un raspuns pe mai
multe linii).

Tabelul de mai jos listeaza alternativ replicile pentru succes si esec pentru fiecare comanda.
Un server poate substitui textul replicilor, dar intelesul si actiunea implicate de numerele
de cod si de secventa de replici specifica comenzii nu pot fi schimbate.

Scvente de Replici la comenzi

In aceasta sectiune, sunt prezentate secventele de raspuns la comenzi. Fiecare comanda este
prezentata cu raspunsurile sale posibile; grupurile de comenzi sunt prezentate impreuna.
Raspunsurile preliminarii sunt listate mai intai, apoi terminarile cu sau fara succes, si
in final raspunsurile intermediare cu comenzile in sectiunea urmatoare. Aceste prezentari
formeaza baza pentru diagramele de stare, care vor fi prezentate separat.

Stabilirea conexiunii
120
220
220
421

Conectare
USER
230
530
500, 501, 421
331, 332
PASS
230
202
530
500, 501, 503, 421
332
ACCT
230
202
530
500, 501, 503, 421
CWD
250
500, 501, 502, 421, 530, 550
CDUP
200
500, 501, 502, 421, 530, 550
SMNT
202, 250
500, 501, 502, 421, 530, 550

Deconectare
REIN
120
220
220
421
500, 502
QUIT
221
500

Transferul parametrilor
PORT
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE
200
500, 501, 504, 421, 530
TYPE
200
500, 501, 504, 421, 530
STRU
200
500, 501, 504, 421, 530

Comenzile care actioneaza asupra fisierelor
ALLO
200
202
500, 501, 504, 421, 530
REST
500, 501, 502, 421, 530
350
STOR
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
STOU
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
RETR
125, 150
(110)
226, 250
425, 426, 451
450, 550
500, 501, 421, 530

LIST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
APPE
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
RNFR
450, 550
500, 501, 502, 421, 530
350
RNTO
250
532, 553
500, 501, 502, 503, 421, 530
DELE
250
450, 550
500, 501, 502, 421, 530
RMD
250
500, 501, 502, 421, 530, 550
MKD
257
500, 501, 502, 421, 530, 550
PWD
257
500, 501, 502, 421, 550
ABOR
225, 226
500, 501, 502, 421

Comenzile informationale
SYST
215
500, 501, 502, 421
STAT
211, 212, 213
450
500, 501, 502, 421, 530
HELP
211, 214
500, 501, 502, 421
Comenzi amestecate
SITE
200
202
500, 501, 530
NOOP
200
500 421

6. DIAGRAMELE DE STARE

In aceasta sectiune prezentam diagramele de stare pentru o foarte simpla implementare FTP.
Doar prima cifra a codului de raspuns este folosita. Este o singura diagrama de stare pentru
fiecare grup de comenzi FTP sau secventa de comenzi.

Grupurile de comenzi au fost determinate mai degraba prin construirea unui model pentru
fiecare comanda decat prin adunarea la un loc a comenzilor cu modele structurale identice.

Pentru fiecare comanda sau secventa de comenzi sunt posibile trei efecte: succes (S),
esec (F), si eroare (E). In diagramele de stare de mai jos folosim simbolul B pentru
"begin", si simbolul W pentru "wait for reply".

Prezentam mai intai diagrama care reprezinta cel mai larg grup de comenzi FTP:

1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+

Diagrama modeleaza comenzile:

ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV,
QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE.

Un alt grup extins de comenzi este reprezentat printr-o diagram asemanatoare:

3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ --->+---+ +---+
| | |
| | | 4,5 +---+
| 1 | ----------->| F |
----- +---+

Diagrama modeleaza comenzile:

APPE, LIST, NLST, REIN, RETR, STOR, and STOU.

Acest al doilea model ar putea de asemenea fi utilizat pentru reprezentarea primului
grup de comenzi, singura diferenta fiind doar ca in primul grup seria de replici 100
sunt neasteptate si de aceea sunt tratate drept erori, in timp ce al doilea grup
asteapta replicile 100. Amintiti-va ca o singura serie de raspunsuri 100 este permisa
pentru o comanda.

Dintre celelate diagrame ale secventelor de comenzi, cea mai simpla probabil este
secventa de redenumire:

+---+ RNFR +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ RNTO +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+

Diagrama este un model simplu al comenzii Restart:

+---+ REST +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 3 | | +---+
| 2| --------
| | | |
V | | |
+---+ cmd +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ -->+---+ +---+
| |
| 1 |
------

Unde "cmd" este APPE, STOR, or RETR.

Remarcam faptul ca cele trei modele de mai sus sunt similare. Repornirea difera
de Redenumire doar prin modul de tratare a seriei de replici 100 in cel de-al
doilea stadiu, in timp ce cel de-al doilea grup asteapta seria de replici 100.
Amintiti-va ca o singura serie de raspunsuri 100 este permisa pentru o comanda.

Cea mai complicata diagrama este pentru secventa de Login:

1
+---+ USER +---+------------->+---+
| B |---------->| W | 2 ---->| E |
+---+ +---+------ | -->+---+
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1| | | |
V | | | |
+---+ PASS +---+ 2 | ------>+---+
| |---------->| W |------------->| S |
+---+ +---+ ---------->+---+
| | | | |
3 | |4,5| | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3| | | |
V | 2| | |
+---+ ACCT +---+-- | ----->+---+
| |---------->| W | 4,5 -------->| F |
+---+ +---+------------->+---+

In final, prezentam o diagrama generalizata care poate fi folisita pentru a modela o
comanda si schimburile de replici:

------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End

7. Scenariul tipic FTP

Clientul de pe masina U asteptand sa transfere fisiere de la/la masina S:

In general, utilizatorul va comunica cu serverul printr-un proces client FTP intermediar.
Urmatorul ar putea fi un scenariu tipic. Replicile user-ului FTP sunt incluse intre paranteze,
'---->' reprezinta comanda de la gazda U la gazda S, iar '<----' reprezinta replica de la
gazda S la gazda U.

COMENZI LOCALE ALE USER-ULUI ACTIUNEA IMPLICATA

ftp (host) multics<CR> Conectarea la gazda S, portul L,
stabilind conexiunea de control.
<---- 220 Service ready <CRLF>.
username Doe <CR> USER Doe<CRLF>---->
<---- 331 Numele utilizatorului ok,
introduceti parola<CRLF>.
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 User logat<CRLF>.
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> User FTP deschide fisier local in ASCII.
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 Starea fisierului OK;
se deschide o conexiune de date<CRLF>.
Serverul reliazeaza oconexiune de date la portul U.
<---- 226 Inchidera conexiunii de date,
transfer de fisiere cu succes<CRLF>.
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Comanda OK<CRLF>
store (local type) image<CR>
(local pathname) file dump<CR> User-ul FTP deschide un fisierlocal in Image..
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Acces interzis<CRLF>
termina QUIT <CRLF> ---->
Serverul inchide toate conexiunile.

8. Stabilirea conexiuniiT

Conexiunea de control FTP este stabilita prin protocolul TCP intre procesul user-ului de la
portul U si procesul serverului de la portul L. Acestui protocol ii este atribuit portul 21
(25 in octal), iar L=21.

ANEXA I - STRUCTURA PAGINII

Nevoia FTP-ului de a suporta structura paginii deriva in principal din nevoia de a suporta
transmisia eficienta a fisierelor intre sistemele TOPS-20, in special fisierele folosite
de NLS.

Sistemul de fisiere pentru TOPS-20 se bazeaza pe conceptul de pagini. Sistemul de operare
este mai eficient cand manipuleaza fisierele ca si pagini. Sistemul de operare are o interfata
pentru sisitemul de fisiere astfel incat multe aplicatii vad fisierele ca fluxuri secventiale
de caractere. Oricum, putine aplicatii folosesc structuira de pagina de baza direct, si unele
dintre acestea creeaza fisiere cu lacune.

Un TOPS-20 fisier consta din patru aspecte: o cale, un tabel de pagina, un set de pagini
(posibil gol), si un set de atribute.

Calea este specificata in comanda RETR sau STOR. Include numele directorului, numele fisierului,
extensia fisierului, si numarul generat.

Tabela de pagina contine pana la 2*18 intrari. Fiecare intrare poate fi goala, sau poate
indica catre o pagina. Daca nu este goala, contine biti specifici de acces la pagini; nu
toate paginile cerute pentru un fisier au aceeasi protectie pentru acces.

O pagina este un set continuu de 512 cuvinte de 36 biti fiecare.

Atributele unui fiser, in Blocul de Descriere a Fisierului (FDB), contin informatii despre
momentul creerii, scrierii, citirii, dimensiune, sfarsitul de fisier, numarul citirilor si
scriierilor, sistemul de backup, etc.

De observat ca nu este necesar ca intrarile in tabela paginii sa fie continue. Pot fi
zone goale printre cele ocupate. De asemenea, sfrsitul de fisier este un simplu numar.
Nu exista nici o cerinta care sa indice ultima data in fisier. Accesele I/O secventiale
obisnuite in TOPS-20 vor cauza ca indicatorul sfarsitului de fisier sa fie lasat dupa
ultima data a scrierii, dar alte operatii nu vor determina acelasi lucru, daca este cerut
un program de sistem particular.

De fapt, in ambele cazuri speciale, fisierele "gaurite" si indicatorii de sfarsit de fisier,
nu de la sfarsitul fisierului, se imbina cu datele NLS despre fisier.

Fisierele paginate de tip TOPS-20 pot fi transmise cu parametrii FTP de transfer: TYPE L 36,
STRU P, si MODE S (de fapt, poate fi folosit orice mod).

Fiecare pagina cu informatii are un antet. Fiecare camp din antet, care este un octet logic,
este un cuvant TOPS-20, din moment ce Tipul este L 36.

Campurile antetului sunt:

Cuvantul 0: Lungimea antetului

Lungimea antetului este 5.

Cuvantul 1: Indexul paginii

Datele sunt o pagina de fisier de pe disk, acesta fiind numarul
acelei pagini in harta de pagini a fisierului. Paginile goale
(gaurile) din fisier nu sunt trimise. De remarcat ca o gaura nu
este acelasi lucru cu o pagina de zerouri.

Cuvantul 2: Lungimea datelor

Numarul cuvintelor de date din pagina, potrivit informatiilor din
antet. Astfel, lungimea totala a unitatii de trasmitere este Lungimea
antetului plus Lungimea datelor.

Cuvantul 3: Tipul paginii

Un cod pentru tipul de zona de date este acesta. O pagina de date este
de tipul 3, iar FDB-ul paginii este de tipul 2.

Cuvantul 4: Controlul Accesului la Pagina

Bitii de acces asociati cu pagina in harta de pagini a fisierelor.
(Acest cuvant este pus in AC2 al unui SPACS de catre programul care
citeste de pe net disk.)

Dupa antet sunt cuvintele cu Lungimea Datelor. Lungimea Datelor este in mod obisnuit 512
pentru paginilede date sau 31 pentru un FDB. Zerourile suplimentare dintr-un pagina unui
fisier pot fi descarcate, facand Lungimea Datelor mai mica decat 512 in acest caz.

ANEXA II - COMENZILE PENTRU DIRECTOARE

Deoarece UNIX are o structura de directoare arborescenta in care directoarele sunt usor
de manipulat la fel ca fisierele obisnuite, este utila extinderea serverelor FTP pe aceste
masini prin includerea de comenzi care sa trateze crearea de directoare. Existand si alte
gazde pe ARPA-Internet care au structura de directoare arborescenta (inclusiv TOPS-20 si
Multics), aceste comenzi sunt cat se poat de generale:

Patru comenzi pentru directoare au fost adaugate la FTP:

MKD cale

Creeaza un director cu numele din "cale".

RMD cale

Sterge directorul cu numele din cale.

PWD

Afiseaza numele directorului curent de lucru.

CDUP

Schimba directorul curent de lucru in directorul parinte.

Argumentul "calea" ar trebui creat (sters) ca un subdirector al directrorului curent de lucru,
daca nu "calea" contine suficiente informatii astfel incat sa specifice altceva serverului,
de ex., "calea" este o cale absoluta (in UNIx si Multics), sau calea este ceva ca
"<abso.lute.path>" in TOPS-20.

CODURILE REPLICILOR

Comanda CDUP este un caz special al comenzii CWD, si a fost inclusa pentru a simplifica
implementarea programelor pentru transferul arborilor de directoare intr sisteme de operare
avand sintaxe diferite pentru numire directorului parinte. Codurile replicilor pentru CDUP
sunt identice cu cele pentru CWD.

Codurile de raspuns pentru RMD sunt identice cu cele pentru comanda sa analoaga pentru
fisiere, DELE.

Codurile de raspuns pentru MKD sunt un pic mai complicate. Un director nou creat va fi
probabil obiectul unei viitoare comenzi CWD. Din nefericire, argumentul lui

MKD nu va fi intotdeuna unul potrivit pentru CWD. Acesta este cazul, de exemplu, cand un
subdirector TOPS-20 este creat prin specificarea doar a numelui subdirectorului. Aceasta este,
intr-un server TOPS-20, o secventa de comenzi care va esua.

MKD MYDIR
CWD MYDIR

Noul director poate fi referit doar prin numele sau "absolut"; de ex., daca comanda MKD
de mai sus va fi lansata fiind deschis un director <DFRANKLIN>, noul subdirector
va putea fi referit doar prin nume <DFRANKLIN.MYDIR>.

Chiar si pe UNIX si Multics, argumentul dat comenzii MKD poate sa nu fie potrivit. Daca
este o cale "relativa" (de ex., o cale care este interpretata relativ la directorul curent),
utilizatorul trbuie sa se afle in acelasi director curent pentru a avea acces la subdirector.
In functie de aplicatie, acesta poate fi un inconvenient. Nu este robust in nici un caz.

Pentru a rezolva aceasta inconvenienta, ca o completare a comenzii MKD, serverul trebuie
sa returneze o linie de forma:

257<space>"<directory-name>"<space><commentary>

Serverul va spune utilizatorului ce sir de caractere sa foloseasca cand vrea sa se refere
la directorul creat . Numele directorului poate contine orice caracter; incadrat intre ghilimele.

De exemplu, un utilizator se conecteaza la directorul /usr/dm, si creeaza un subdirector, numit:

CWD /usr/dm
200 directorul curent schimbat in /usr/dm
MKD cale
257 "/usr/dm/pathname" directorul creat

Un exemplu cu incadrarea intre ghilimele:

MKD foo"bar
257 "/usr/dm/foo""bar" directorul creat
CWD /usr/dm/foo"bar
200 directorul curent schimbat in /usr/dm/foo"bar

Existenta deja a unui director cu acelasi nume este o eroare, si serverul terbuie sa returneze
o eroare de "acces interzis" in acest caz.

CWD /usr/dm
200 directorul curent schimbat in /usr/dm
MKD clae
521-"/usr/dm/pathname" directorul exista deja;
521 nu se intreprinte nici o actiune.

Replicile de esec pentru MKD sunt analoage cu cele de la crearea fisierului, STOR. De asemenea,
o replicaz de "acces interzis" este data daca numele unui fisier cu acelasi nume ca si
subdirectorul va intra in conflict cu crearea subdirectorului (acasta este o problema in UNIX,
dar nu ar trebui sa fie in TOPS-20).

Deoarece comanda PWD returneaza acelasi tip de informatie la succes ca si comanda MKD, comanda PWD
la succes foloseste de asemenea codul de raspuns 257.

PRECIZARI

Deoarece aceste comenzi vor fi mai folositoare pentru transferul sub-arborilor de pe o
masina pe alta, se observa ca argumentul pentru MKD poate fi mai degraba ca un subdirector
al directorului curent de lucru, in afara cazului cand contine suficiente informatii
pentru gazda destinatie astfel incat aceasta sa inteleaga altfel. Un exemplu ipotetic
pentru aceasta utilizare este lumea TOPS-20:

CWD <some.where>
200 directorul de lucru este schimbat
MKD overrainbow
257 "<some.where.overrainbow>" director creat
CWD overrainbow
431 Nu exista un astfel de director
CWD <some.where.overrainbow>
200 directorul de lucru este schimbat

CWD <some.where>
200 directorul de lucru este schimbat in <some.where>
MKD <fara echivoc>
257 "<fara echivoc>" director creat
CWD <fara echivoc>

Remarcati faptul ca in primul exemplu rezulta un subdirector al directorului curent.
In opozitie, argumentul celui de-al doilea exemplu contine suficiente informatii pentru
TOPS-20 pentru a-i spune acestuia ca directorul <fara echivoc> este un director
de nivel inalt. De remarcat de asemenea faptul ca in primul exemplu utilizatorul "violeaza"
protocolul asteptand sa acceseze directorul nou ceat cu un alt nume decat cel returnat de
TOPS-20. Problemele care pot rezulta in acest caz pot fi la directorul <overrainbow>
aceasta este o ambiguitate mostenita in unele implementari TOPS-20. Consideratii similare
sunt valabile si pentru comanda RMD. Ideea este aceasta: cu exceptia cazurilor in care ar
proceda astfel utilizatorul ar viola conventiile gazdei in ceea ce priveste caiile absolute
si caile relative, gazda ar trebui sa trateze operanzii comenzii MKD si RMD ca subdirectoare.
Raspunsul 257 la comanda MKD trebuie sa contina intotdeauna calea absoluta a directorului creat.

ANEXA III - RFCs on FTP

Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
MIT-Project MAC, 16 April 1971.

Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.

Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.

Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663),
UCLA/CCN, 29 September 1971.

Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
(NIC 7813), MIT-Project MAC, 17 November 1971.

McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
RFC 281 (NIC 8163), BBN, 8 December 1971.

Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
25 January 1972.

Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
MIT-Project MAC, 8 July 1972.

Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.

Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
27 November 1972.

Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further
Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972.

Braden, Bob, "Comments on File Transfer Protocol", RFC 430
(NIC 13299), UCLA/CCN, 7 February 1973.

Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction",
RFC 438 (NIC 13770), BBN, 15 January 1973.

Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN,
27 February 1973.

McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN,
16 February 1973.

Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458
(NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973.

Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN,
12 July 1973.

Krilanovich, Mark, and George Gregg, "Comments on the File Transfer
Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974.

Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the
File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974.

Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White,
"Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB,
Ames Research Center, SRI-ARC, 28 February 1974.

Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463
(NIC 14573), MIT-DMCG, 21 February 1973.

Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN,
8 March 1973.

Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919),
MIT-DMCG, 6 March 1973.

Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II",
RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973.

White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948),
SRI-ARC, 8 March 1973.

White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949),
SRI-ARC, 8 March 1973.

Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506
(NIC 16157), MIT-Multics, 26 June 1973.

Day, John, "Memo to FTP Group (Proposal for File Access Protocol)",
RFC 520 (NIC 16819), Illinois, 25 June 1973.

Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532
(NIC 17451), UCSD-CC, 22 June 1973.

Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN,
15 November 1973.

McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation -
Schedule Change", RFC 593 (NIC 20615), BBN and MITRE,
29 November 1973.

Sussman, Julie, "FTP Error Code Usage for More Reliable Mail
Service", RFC 630 (NIC 30237), BBN, 10 April 1974.

Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843),
UCLA/NMC, 5 June 1974.

Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481),
SU-AI, 10 May 1975.

Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI,
28 May 1975.

Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975.

Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL,
31 October 1977.

Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758),
SRI-KL, 30 December 1977.

Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT,
10 December 1978.

Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI,
June 1980.

Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
Commands", RFC 776, BBN, December 1980.

Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE,
July 1985.

REFERINTE

[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook",
Network Information Center, SRI International, March 1982.

[2] Postel, Jon, "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.

[3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol
Specification", RFC 854, ISI, May 1983.

[4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943,
ISI, April 1985.