:
Protokol stworzyl Noel Chiappa, pozniej protokol zostal przerobiony przez niego, K.R.Sollinsa (autor [1] i [2]), Boba Baldwina oraz Dave'a Clarka z uwzglednieniem uwag Steve'a Szymanskiego. Ostatnia wiersja protokolu powstala w roku 1992 jako wynik dyskusyj z duza iloscia ludzi (p. [2]). W tej wersji zostaly wyeliminowane niescislosci, isniejace w [1]. Przy tworzeniu protokolu idea potwierdzen oraz schemat retransmisji byly wziete z protokolu TCP, mechanizm obslugi bledow zostal wziety z PARC's EFTP abort message.
W jezyku angelskim nazwa brzmi nastepujaco: "Trivial File Transfer Protocol". Pierwotne przeznaczenie tego protokolu - przekazywanie plikow po roznych sieciach ze zrealizowanym na nich protokole UDP. TFTP jawil sie poprzednikiem znacznie bardziej rozbudowanego protokolu FTP[4], zrealizowanego na podstawie protokolu TCP. TFTP potrafi przekazywac teksty, poczte oraz pliki binarne. Nie sa dostepne natomiast mozliwosci identyfikacji uzytkownika czy przekazania listy plikow w katalogu. Jest to jednak zrozumiale, bo przy projektowaniu protokolu zwracano uwage glownie na latwosc realizacji. Jak w wiekszosci internetowych protokolow, wielkosc jednego bajtu wynosi 8 bitow.
W roku 1984 bylo zaproponowane uzywac ten protokol do pierwotnego inicjalizowania bezdyskowych terminali. Ten projekt razem z opisem sposobu ladowania znajduje sie w [3]. Taka propozycja jest zrozumiala, bo protokol UDP jest zaimplemientowany prawie w kazdej sieci, a poniewaz jest to bardzo prosty protokol, to implementacje latwo mozna umiescicz w ROM. To samo dzieje sie z TFTP. Jest to bardzo prosty protokol, implementacja ktorego nie zajmuje wiele miejsca, wiec tez z latwoscia umiesci sie w ROM. Zbyt wolne dzialanie algorytmu mozna wyeliminowac w bardzo prosty sposob - uzywajac TFTP zaladowac modul do obslugi bardziej szybkiego protokolu i reszte operacji po inicjalizowaniu systemu wykonac z ejgo uzyciem.
Protokol TFTP uzywa 3 tryby przekazywania informacji:
Kazda transmisja zaczyna sie z rzadania o odczyt lub o zapis, ktore jest jednoczesnie do rzadania na polaczenie. Jezeli serwer chce sie komunikowac, to polaczenie sie odtwiera i dane przesylaja sie w standartowych blokach po 512 bajtow. Kazdy pakiet danych zawiera jeden blok danych i jego otrzymanie musi byc potwierdzone przed przekazaniem nastepnego pakietu danych. Pakiet danych dlugosci mniejszej niz 512 bajtow (0..511) oznacza koniec transmisji. Jezeli pakiet danych nie dojdzie do odbiorcy to nie bedzie rowniez wyslane potwierdzenie. W tym przypadku komputer wysylajacy dane po uplywie pewnego czasu (timeout) wysyla te dane jeszcze raz. Przekazujacy komputer musi trzymac w pamieci tylko jeden pakiet danych az przyjdzie pakiet potwierdzajacy odbior. Nalezy zauwazyc ze oba dwaj komputery - odbierajacy i wysylajacy zajmuja sie jak przekazywaniem tak i odbiorem pakietow. Jeden wysyla dane i odbiera potwierdzenia, drugi zas - wysyla potwierdzenia i odbiera dane.
Wiekszosc bledow powoduje rozlaczenie polaczenia. Komunikat o bledzie wysyla sie za pomoca ERROR-pakietu. Odbior tego pakietu nie potwierdza sie jak nie przekazuje sie drugi raz (jest to zrozumiale bo uzytkownik albo serwer mogli zakonczyc swoja dzialalnosc zaraz po wyslaniu komunikatu o bledzie). W ten sposob komunikat o bledzie moze niegdy nie dojsc do odbiorcy. Dlatego uzywa sie rowniez mechanizmu timeout do wykrycia konca polacznia. Bledy moga sie pojawic w trzech przypadkach:
TFTP ma tylko jeden typ bledu, ktory nie powoduje zakonczenia transmisji: jezeli port zrodlowy (source port) przyjetego pakietu jest zly. W tym przypadku komunikat o bledzie wysyla sie do tego portu.
Poniewaz TFTP zostal zaprojektowany jako protokol, uzywajacy UDP, a UDP uzywa do komunikacji protokolu IP, pakiety beda mieli IP-nadglowek, UDP-nadgluwek oraz TFTP-nadglowek. Oprocz tego, pakiet moze miec inne nadglowki (LNI, ARPA etc.) ktore pozwolaja mu przejsc przez siec lokalna. W ten sposob mamy nastepujacy porzadek w nadglowkiu:
| Lokalny(jezeli jest) | IP | UDP | TFTP |
TFTP nie uzywa danych z IP-nadglowka ale uzywa porty zrodlowy i docelowy (source&destination ports) z nadglowka UDP, jak rowniez i pola dlugosci do sprawdzenia dlugosci pakietu TFTP.Identyfikatory przekazu (transfer identifiers albo TID), ktorych uzywa TFTP umieszcza sie w warstwie UDP. Dlatego ich wartosci leza w przedziale 0..65535. Inicjalizacja TID szczegolowe zostala opisana w nastepnym punkcie.
Transmisja rozpoczyna sie od zapytania o odczyt (RRQ) albo o zapis (WRQ) i odbierania pakietu potwierdzajacego (ACK) w przypadku pozwolenia na zapis albo pierwszego pakietu z danymi w przypadku prosby o odczyt.
W ogolnym przypadku pakiet potwierdzajacy ma numier ostatne otrzymanego pakietu danych. Te numiery zaczynaja sie od 1 i leza w porzadku rosnacym. W przypadku potwierdzenia prosby o zapis wysyla sie potwierdzajacy pakiet z numierem bloku 0. Jezeli przychodzi ERROR-pakiet, to oznacza ze polaczenie nie jest mozliwe.
Dla tworzenia polaczenia przekazujacy i otrzymujacy komputery powinni wybrac dla siebe TID. Poniewaz numery te wybiera sie w sposob losowy, prawdopodobienstwo tego, ze wybrane TID'y sa jednakowe jest male. Kazdy pakiet ma dwa TID'y: source TID i destination TID, ktorych uzywa UDP jako source i destination portow. Probujacy nawiazac kontakt host ustawia source port sposobem opisanym wyzej i wysyla zapytanie na znany TID 69 (jest zarezerwowany do TFTP). Reagujac na prosbe odpowiadajacy host wybiera za pomoca tego samego sposobu swoj TID i uzywa otrzymanego TID'u jako destination. Otrzymane w ten sposob TID'y uzywa sie w czasie calej sesji.
Na przyklad, przy prosbie na zapis pliku wykonuja sie nastepujace czynnosci:
Moze zajsc sytuacja ze source TID nie jest rowny poczatkowo wybranemu (takie cos moze byc spowodowane awarija w sieci etc.). W tym wypadku otrzymany pakiet uwaza sie za zgubiony z innej transmisji pakiet. Informacja o bledzie ma byc wyslana pod ten niewlasciwy TID. Nastepujacy przyklad opisuje dzialania systemu, jezeli zaistniala powyzsza sytuacja:
TFTP ma 5 rodzajow pakietow:
| Kod | Operacja |
| 1 | Read Request (RRQ) |
| 2 | Write Request (WRQ) |
| 3 | Dane(DATA) |
| 4 | Potwierdzenie (ACK) - Acknowlegment |
| 5 | Blad (ERROR) |
2 bajty String 1 bajt Sring 1 bajt
| Kod | Nazwa pliku |
0 |
Tryb | 0 |
Host, otrzymajacy dane w postaci NetASCII poninien ich przeksztalczyc we wlasny format. Dobrym przykladem jest DOS i UNIX z roznymi kodami konca wiersza. Wlasnie dla tego przy przepisaniu binarnych plikuw z ustawieniem ASC w FTP dostajemy bzdury!
Dane w formacie "Octet" musza sie przekazywac w niezmienionym stanie. W szczegolnosci jezeli wyslany wczesniej plik przekazac z powrotem, to otrzymana kopia nie powinna sie roznic od oryginalu. Trzeba pamietac ze jesli przekazujacy komputer ma dlugosc slowa nie rowna 8 bit, to przed przekazywaniem dane musza byc przeksztalcone w format z 8-bitowym slowem. Taki format danych byl uzyty jako najberdziej ogolny i prosty dla przeksztalcenia. Na przyklad DEC-20 ma 36-bitowe slowo, wiec mozna go przedstawic jako 4 8-bitowych slowa oraz jedna "polowke".
Przy przykazywaniu listow zamiast nazwy pliku wpisuje sie adres uzytkownika. Moze byc w formie "username", albo "username@hostname"
Mozliwe sa rowniez inne tryby, ale trzeba z nimi uwazac, bo oni nie naleza do standartu.
2 bajty 2 bajty n bajtow
| 3 | Numer bloku | Dane |
Zauwazmy ze blokow maksymalne moze byc 65.535, inymi slowy maksymalna dlugosc przekazywanego pliku wynosi 33.553.920 bajtow.
2 bajty 2 bajty
| 4 | Numer bloku |
Przyjscie kazdego pakietu danych powinno byc potwierdzone. Jest to jedyny miechanizm ochrony danych zastosowany w TFTP. Komputer przekazujacy dane nie bedzie przekazywal kolejnego bloku puki nie otrzyma informacje o dojsciu poprzedniego bloku danych albo nie uplynie czas wyznaczony na oczekiwanie odpowiedzi (timeout). W tym przypadku dane beda wyslane jeszcze raz.
Jak juz pisalem wczesniej, prosba o zapis potwierdza sie ACK - pakietem z numierem bloku danych 0.
Przyklad polaczen:
:
Odczyt Zapis
2 bajty 2 bajty String & nbsp; 1 bajt
| 5 | Error Code | Error Message | 0 |
ERROR-pakiet moze byc potwierdzajacym dla dowolnego typu pakietow. Opis bledu (Error message) powinno byc w formacie NetASCII. Otrzymanie ERROR-pakietu nie trzeba potwierdzac, jak rowniez nie trzeba go wysylac ponownie w przypadku stracenia tego pakietu gdzies w sieci (procesy moga skonczyc dzalanie zaraz po wyslaniu komunikatu o bledzie). Oto sa kody bledow:
|
Kod |
Rodzaj |
|
0 |
Nie zdef. rodzaj bledu, zob. Error Message (o ile istnieje) |
|
1 |
Plik nie zostal znaleziony |
|
2 |
Naruszenie praw dostepu |
|
3 |
Przepelnienie albo przekroczenie przydzialu pamieci |
|
4 |
Niodozwolona operacja TFTP |
|
5 |
Nie znany numer portu |
|
6 |
Plik juz istnieje |
|
7 |
Nie ma takiego uzytkownika |
Pakiet danych DATA, majacy 0..511 bajtow informacji (dlugosc pakieta UDP <516)) oznacza koniec transmisji. Otrzymanie tego pakietu potwierdza sie pakietem ACK tak samo, jak wszystkie przed nim. Komputer, ktory otrzymal juz wszystkie dane musi poczekac by przekazac pakiet ACK jeszcze raz, jezeli poprzedni zniknie w sieci. W tym wypadku przekazujacy komputer wyszle ostatnie dane jeszcze raz po uplywie czasu oczekiwania. Przekazujacy komputer powinien wysylac te dane az dostanie ACK albo uplynie czas oczekiwania dla wyslania. Jesli przyszedl pakiet ACK polaczenie bylo dobrym. Jezeli nie, to nie wiadomo, albo dane dotarly do odbiorcy i zgubily sie wszystkie pakiety ACK, albo dane nie dotarly. W kazdym razie transmisja jest przerwana.
Jesli nie otrzymalismy zezwolenia na dostep od zasobu albo pojawil sie blad w trakcie transmisji to wysyla sie pakiet bledu ERROR. On nigdy nie wysyla sie dwa (albo wiecej) razy i nigdy sie nie potwierdza. Jak widac, on moze nigdy nie zostac otrzymany. W tym wypadku pomaga mechanyzm timeout.
Problem polega na tym, ze realizacja tego protokolu nie wchodzi do jadra Linuxa. Natomiast pelny kod zrodlowy klienta i serwera TFTP ze szczegolowymi komientarzami znajduje sie w [5], str. 520. Jak pewnie widac realizacja tego protokolu nie jest ani ciekawa, ani skomplikowana. Wlasne dlatego przy tworzeniu tego dokumientu kierowalem sie raczej [1] i [2] niz [5].
Tak! W [5] zostalo to nawiet zrealizowane dla TCP