8.4.2 File Transfer Protocol (overview)





Do spisu tresci tematu 8 Rosyjska wersja dokomientu (win1251)]


8.4.2 Protokol FTP (przeglad)





Spis tresci



Wstep
Troche histori
Jak to dziala
Bibliografia
Pytania i odpowiedzi






Wstep


Protokol FTP byl zaprojektowany do nastepujacych zastosowan:


do podtrzymania wspolengo uzywania plikow (programy komputerowe i/lub dane);
do podtrzymania zdalnego uzywania komputerow;
do aktualizowania wesij programow na serwerach plikow;
do dokladnej i skutecznej transmisji plikow.


Chociaz FTP moze byc uzywany przez uzytkownika wprost na terminalu,
jednak przy projektowaniu zakladalo sie iz bedzie on wykorzystywany przez
programy.

Glownym zastosowaniem protokolu jest zaspokojenie potrzeb uzytkownikow
duzych i malych hostow i terminali z mozliwoscia latwej implementacji.



Troche historii

FTP ma dluga historie. Pierwszy raz mechanizm przekazywania plikow byl
zaproponowany w roku 1971 i zrealizowany dla hosta na M.I.T (patrz RFC114
z komientarzami w RFC141).

W RFC172 zostal opisany zorientowany na uzytkownika protokow transmisje
plikow pomiwdzy hostami (lacznie z terminalami IMPs). W RFC265 i RFC281
niekture aspekty zostaly zmienione. Pojencie "Set Data Type"
zostalo wprowadzone w RFC294 w styczniu 1972 roku.

RFC354 uzupelnil RFC264 i RFC265. File Transfer Protocol byl teraz zdefinowany
jako protokol do transmisji pomiedzy HOST'ami dla ARPANET. Najbardziej
istotnej funkcjej protokolu byla nazwana funkcja przekazywania plikow miedzy
hostami skutecznie i dokladnie. To musialo pomagac w uzyciu serwerow plikow.
Pozniej pojawilo sie sporo dokomientow RFC na ten temat. Oto sa niektore:
RFC385, RFC414, RFC430. Pierwsza "oficjalna" wersja protokolu
zostala opublikowana w RFC454.

W lipcu roku 1973 byly wyprawione niektore niescislosci, ale struktura
protokolu pozostala taka sama. Wszystkie te zmiane byly zaznaczone w RFC542
- nowej "oficjalnej" wersji protokolu.

W roku 1974 ciagle trwaly dyskusje na ten temat. Jako ich wynik pojawily
sie nastepujace dokumienty: RFC607, RFC614, RFC624, w 1975 roku - RFC686,
RFC691.

W zwiazku z przejsciem protokolu nizszej warstwy z NCP na TCP pojawil
sie nowy dokumient, opisujacy standart: RFC765,

Ostatnia specyfikacja (ktora potrafilem odnalezc) protokolu pojawila
sie w pazdzierniku roku 1985 pod numerem RFC959. W tym dokumiencie zostaly
wyprawione pewne niejednoznacznosci oraz wrpowadzono kilka opcjonalnych
komand.



Jak to dziala.


Obrazek, podany nizej przedstawia strukture FTP serwisu:







Uwagi: 1. Data Connection moze byc uzywany w obudwoch kierunkach

2. Data Connection moze nie istniec


PI - interpretator protokolu (Protocol Interpreter). Protokol ze strony
uzytkownika i serwera jest zrealizowany w rozny sposob dla User-PI i Server-PI.

Server-PI - protokol serwera oczekuje w portu X polaczenia z User-PI
i inicjalizuje polaczenie. On przyjmuje standartowe polecenia od User-PI,
wysyla odpowiedzi i kieruje Server-DTP-om.

User-PI - interpretator protokolu uzytkownika jest inicjatorem tworzenia
polaczenia ze swego portu Y z procesem Servr-FTP, wysyla FTP polecenia
oraz kieruje User-DTP, o ile taki proces sie pojawi.

Server-DTP - proces przekazywania danych (Data Transfer Process) w
swoim zwyklym "aktywnym" stanie ustawie polaczenia "sluchajac"
port danych. On ustawia paramietry do wysylania i odbioru i przekazuje
dane z poleceniami od Server-PI

User-DTP - proces przekazywania danych "slucha" port danych
dla polaczenia z procesem Server-FTP. Kiedy dwaj serwerzy przekazuja dane,
User-DTP jest w "nieaktywnym" stanie.


W modelu przedstawionym na obrazku User-PI inicjalizuje polaczenie kierujace
(control connection) ktore sie realizuje zgodnie z Telnet protocolem. Polecenia
stworzone przez uzytkownika przeksztalcaja sie w User-PI i przekazuja sie
procedowi serwera przez polaczenie kierujace. Standartowe odpowiedzi przesylaja
sie od Serwer-PI do User-PI przez polaczenie kierujace.

Polecenia FTP definuja paramietry dla polaczenia danych (data connection):
port danych, tryb przekazu, typy przedstawienia danych i struktur, oraz
typ operacji: zachowanie zmian, wyszukiwanie, dodawanie, kasowanie etc.).
User-DTP powinien "sluchac" zdefinowany port danych a serwer
zdefinuje polaczenie danych (data connection) i przekazywac danych (data
transfer) zgodnie ze zdefinowanymi paramietrami. Zauwazmy ze port danych
(data port) nie koniecznie musi sie znajdowac na tym samym host'cie co
przekazuje polecenia poprzez polaczenie kierujace (control connection),
jednak uzytkownik albo FTP-proces uzytkownika powinien "sluchac"
pewien pord danych. Trzeba rowniez zauwazyc iz polaczenie danych (data
connection) mozy byc uzyte do jednoczesnego przekazu i przejmowania.

Moze powstac sytuacja kiedy uzytkownik chce przekazac pliki miedzy dwomia
hostami, zaden z ktorych nie jest lokalny. W tym przypadku uzytkawnik tworzy
polaczenie kierujace (control connection) z dwomia serwerami a potem organizuje
polaczenie danych (data connection) pomiedzy nimi. W ten sposob, informacja
kierujaca przechodzi przez User-PIm a dane przekazuja sie pomiedzy procesami
przekazu danych serwerow. Oto diagram takiej transmisji:









Protokol zaklada ze polaczenie kierujace jest otwarte poki idzie przekaz
danych. Uzytkownik sam musi pytac o zamkniecie polaczenia kierujacego,
ale wykona to zamkniecie serwer. Serwer moze zakonczyc przekaz danych jesli
polaczenia kierujace zostana zamkniente bez polecenia.

Zwiazek FTP z Telnet Protocol

FTP uzywa Telnet protokow przy tworzeniu polaczenia kierujacego (control
connection). Moze to byc zrobione ne dwa sposoby:


User-PI lub Server-PI moga miec regulu Telnet Protocol'u zaimplemientowanymi
w swoich procedurach;

User-PI lub Server-PI moga uzywac zewnetrzny Telnet modyl


Latwa implementacja, dzielony kod oraz programowanie modulowe wskazuja
na drugi sposob. Jednak skutecznosc i niezaleznosc wskazuja na pierwsza
mietode. W praktyce FTP uzywa niewielka czesc Telnet protokolu, wiec realizacja
pierwszego sposobu nie jest skomplikowana.



Bibliografia



RFC0959. File Transfer
Protocol (FTP). J. Postel, J. Reynolds, October 1985

Programowanie zastosowan sieciowych w systemie
UNIX. R. Stevens




Pytania i odpowiedzi

Dlaczego nie ma kodow zrodlowych?
Po pierwsze ten protokol nie jest realizowany w warstwie jadra Linux'a.
Inna przycina jest to, ze to tylko przeglad. Caly opis protokolu zajmuje
69 stron w jezyku angelskim. Gdybym umiescil go w calosci w tym dokumiencie,
to nie byl by to przeglad ;-)



Autor: Dmitrij Mazar