Celem ćwiczenia jest zaprezentowanie wykorzystania protokołu FTP (tzn. implementujących go narzędzi i samego protokołu). Podrozdziały 1.2 i 1.3 nie są przeznaczone do szczegółowego czytania podczas laboratorium. Kiedy tylko uzyskacie z nich Państwo ogólne informacje, proszę spróbować połączyć się z ftp://ftp.kis.p.lodz.pl i sprawdzić polecenia klienta oraz odpowiedzi serwera.
1. FTP (File Transfer Protocol)
FTP jest popularnym protokołem używanym do kopiowania plików pomiędzy oddalonymi od siebie maszynami. Został zaimplementowany w wielu narzędziach, włączając w to przeglądarki WWW i „user-friendly” narzędzia posiadające wyszukany interfejs graficzny. Jednak podczas tego laboratorium należy posługiwać się konsolowym (tekstowym) klientem FTP, dystrybuowanym np. z Windows 2000 albo RedHat Linux.
1.1. Klient FTP
Ppisane poniżej polecenia pochodzą z UNIXowego klienta FTP. Mogą różnić się od siebie zależnie od konkretnej implementacji. Proszę porównać je z ich „odpowiednikami” z MS Windows (pomoc dotyczącą polecenia można uzyskać wpisując help nazwa_polecenia w konsoli klienta FTP).
Otwieranie i zamykanie połączenia
ftp rozpoczyna sesję FTP
open hostname łączy z podanym hostem
close zamyka połączenie (ale nie sesję FTP!)
quit kończy sesję FTP
Przeglądanie zawartości zdalnej maszyny
dir podaje pełną zawartość katalogu na zdalnej maszynie
dir name* wyświetla tylko pliki i katalogi pasujące do wzoru "name..."
ls tak samo jak dir, ale zapewnia uproszczone wylistowanie nazw plików
Katalogi w FTP
pwd wyświetla nazwę bieżącego katalogu
cd remote_dir zmienia bieżący katalog na zdalnym hoście
cd .. przeskakuje poziom wyżej w strukturze katalogów na zdalnej maszynie
lcd directory zmienia domyślny katalog na lokalnym komputerze
Typy plików
binary przełącza tryb transferu na binarny (do plików binarnych)
ascii przełącza tryb transferu na ASCII (do plików tekstowych)
Przesyłanie plików
get file kopiuje plik "file" ze zdalnego komputera na lokalny (z bieżącego zdalnego katalogu do bieżącego lokalnego katalogu)
mget file1.* file2.dbf kopiuje pliki zaczynające się od "file1" I plik nazwany file2.dbf ze zdalnego na lokalnego hosta.
put file kopiuje plik "file" z lokalnego na zdalny komputer. Wymaga prawa zapisu do katalogu.
mput file1.* file2.dbf kopiuje pliki zaczynające się od "file1" i plik nazwany file2.dbf z lokalnego na zdalny komputer.
quit zamyka połączenie i kończy sesję FTP.
Jeżeli nazwa pliku zawiera spacje (np. w systemach MS WIndows) należy zapisać ją w znakach cudzysłowu „”, jednak zaleca się silnie zmianę nazwy pliku przed przesłaniem go.
Operacje na plikach i katalogach
delete usuwa plik w bieżącym katalogu zdalnej maszyby (jak rm w UNIXie).
mkdir tworzy nowy katalog w bieżącym katalogu
rmdir usuwa catalog w bieżącym katalogu na zdalnej maszynie
Other commands
get file "| more" wyświetla plik "file". W celu upewnienia się, że jest to plik, który nas interesuje, można wyświetlić jego zawartość poprzez polecenie more.
prompt wyłącza potwierdzanie poszczególnych plików w poleceniach mget i mput.
Jeżeli nastąpiła pomyłka w nazwie użzytkownika lub haśle, można użyć komendy user w celu przelogowania. Pełną listę dostępnych poleceń FTP można uzyskać wpisując ? w konsoli FTP. Skrócone wyjaśnienie polecenia uzyskuje się podając jego nazwę po help.
1.2. “Czyste” polecenia i odpowiedzi FTP
Przedstawione powyżej polecenia mogą poważnie różnić się zależnie od implementacji klienta. Bez względu na wszystko, zawsze odpowiadają one za wykonanie pewnych „czystych” poleceń FTP, zgodnie ze specyfikacją FTP (RFC 959), cytowaną w następującej części podrozdziału.
1.2.1. Polecenia kontroli dostępu
Poniższe komendy określają identyfikatory kontroli dostępu (kody poleceń znajdują się w nawiasach).
USER NAME (USER)
Pole argumentu jest napisem zgodnym z Telnet określającym użytkownika. Identyfikacja użytkownika jest wymagana przez serwer dla udostępnienia mu jego systemu plików. Zazwyczaj jest to pierwsze polecenie wysyłane przez użytkownika po ustanowieniu połączeń kontrolnych (wymaganych przez niektóre serwery). Serwer może także żądać dodatkowe informacje identyfikacyjne w formie hasła i/lub polecenia dotyczącego konta. Serwery mogą dopuszczać nową komendę USER w dowolnym momencie w celu zmiany kontroli dostępu i/lub informacji o koncie. Ma to wpływ na czyszczenie użytkownika, hasła i informacji o koncie dotychczas dostarczonych i ponowne rozpoczęcie procedury logowania. Wszystkie parametry transferu pozostają niezmienione i rozpoczęte przesyłanie pliku zostaje dokończone ze starymi parametrami kontroli dostępu.
PASSWORD (PASS)
Pole argumentu jest napisem zgodnym z Telnet określającym hasło użytkownika. To polecenie musi być poprzedzone poleceniem nazwy użytkownika i, dla niektórych serwerów, kończy uwierzytelnianie w celu kontroli dostępu. Ponieważ informacja o haśle nie powinna być jawna, należałoby ogólnie mówiąc ją ukryć. Jednak okazuje się, że serwer nie posiada na to „idiotoodpornego” sposobu. Dlatego odpowiedzialność za to spoczywa po stronie użytkownika FTP.
ACCOUNT (ACCT)
Pole argumentu jest napisem zgodnym z Telnet określającym konto użytkownika. Polecenie niekoniecznie jest powiązane z poleceniem USER, ponieważ niektóre strony mogą wymagać nazwy konta do logowania, a naw użytkowników do określania praw dostępu, jak zapis plików. W takim przypadku komenda ta może pojawić się w dowolnym momencie.
Istnieją odpowiednie kody odpowiedzi, określające te przypadki w celu automatyzacji procedur: kiedy informacja o koncie jest wymagana do logowania, kodem odpowiedzi dla udanego polecenia PASS jest 332. Z drugiej strony, jeżeli ta informacja jest zbędna, pojawia się odpowiedź 230, a jeśli informacja o koncie jest potrzebna dla dalszych poleceń używanych podczas połączenia, serwer powinien zwrócić odpowiedzi 332 albo 532 zależnie od tego, czy w danej chwili zachowuje (za sprawą polecenia ACCT) czy unieważnia polecenie.
CHANGE WORKING DIRECTORY (CWD)
Polecenie to umożliwia użytkownikowi pracę z innym katalogiem albo zbiorem danych dla przechowywania lub pobierania plików bez zmiany loginu czy informacji o koncie. Podobnie, nie zmieniają się parametry transferu. Argumentem jest ścieżka określająca katalog lub inny zależny od systemu desygnator grupy plików.
CHANGE TO PARENT DIRECTORY (CDUP)
Polecenie to jest szczególnym przypadkiem CWD i jest wprowadzone w celu uproszczenia implementacji programów do przesyłania drzew katalogów pomiędzy systemami operacyjnymi używającymi różnych składni do nazywania katalogu nadrzędnego. Kod odpowiedzi powinien być identyczny jak przy zastosowaniu CWD.
STRUCTURE MOUNT (SMNT)
Pozwala uzytkownikowi zamontować strukturę danych innego systemu plików bez zmiany loginu i informacji o koncie. Ponownie, polecenie nie zmienia parametrów transferu. Argumentem jest ścieżka określająca katalog bądź inny zależny od systemu desygnator grupy plików.
REINITIALIZE (REIN)
Polecenie kończy USER, czyszcząc całą informację I/O i dotyczącą konta, jednak pozwalając zakończyć trwające transfery. Wszystkie parametry są resetowane do wartości domyślnych, a połączenie kontrolne jest pozostawione otwarte. Powstający stan jest identyczny do ;tego, w jakim użytkownik znajduje się zaraz po otwarciu połączenia kontrolnego. Można oczekiwać w tym miejscu komendy USER.
LOGOUT (QUIT)
Polecenie kończy USER i jeżeli nie trwa transfer plików, serwer zamyka połączenie kontrolne. Jeżeli transfer trwa, połączenie pozostanie otwarte dla przesłania wyniku i dopiero wtedy serwer je zamknie. Jeżeli trwa transfer dla kilku USER i użytkownik nie chce zamykać i ponownie otwierać połączeń dla każdego z nich, powinien zastosować poleceń REIN zamiast QUIT.
Nieoczekiwane zakończenie połączenia kontrolnego spowoduje, że serwer wykona akcję przerwania operacji (ABORT) i wylogowania (QUIT).
1.2.2. Polecenia parametrów transferu
Wszystkie parametry transferu danych posiadają swoje wartości domyślne i odpowiednie polecenia określające te parametry są wymagane jedynie gdy chcemy te wartości zmienić. Domyślną wartością pozostaje wartość ostatnio określona, a przy jej braku - standardowa wartość domyślna. Wskazuje to, że serwer musi „pamiętać” wartości domyślne. Poniższe polecenia można stosować w dowolnej kolejności, z zastrzeżeniem że muszą one pojawić się przed żądaniem usługi FTP.
DATA PORT (PORT)
Argumentem jest zapis HOST-PORT definiujący port danych używany do połączenia. Istnieją wartości domyślne odnoście portu użytkownika i serwera i w normalnych okolicznościach to polecenie i odpowiedź na nie nie są wymagane. Jeżeli jednak polecenie to jest stosowane, argumentem jest złączenie 32-bitowego adresu hosta i 16-bitowego numeru portu TCP. Informacja o adresie jest podzielona na 8-bitowe pola i wartość każdego z nich jest przesyłana jako liczba dziesiętna (w formie ciągu znaków). Pola są rozdzielone przecinkami, a składnia polecenie PORT jest następująca:
PORT h1,h2,h3,h4,p1,p2
gdzie h1 stanowi 8 najstarszych bitów adresu internetowego hosta.
PASSIVE MODE (PASV)
Polecenie to żąda od serwera “nasłuchiwania” na zadanym porcie (który nie jest domyślnym portem) i czekania na połączenie zamiast otwierania go na potwierdzenia polecenia transferu. Odpowiedź na to polecenie zawiera adres hosta i port, których nasłuchuje serwer.
REPRESENTATION TYPE (TYPE)
Argument określa typ reprezentacji opisany w rozdziale na temat Reprezentacji Danych i Przechowywania, Data Representation and Storage. Drugim parametrem jest szereg typów. Pierwszy parametr jest pojedynczym znakiem zgodnym z Telnet, a drugi parametr „Format” dla ASCII i EBCDIC określający lokalny bajt jest liczbą całkowitą dziesiętną w celu określenia „Bytesize”. Parametry są oddzielone przez <SP> (spacja, kod ASCII 32).
Typ jest opisywany przez następujące kody:
\ /
A - ASCII | | N - Non-print
|-><-| T - Telnet format effectors
E - EBCDIC| | C - Carriage Control (ASA)
/ \
I - Image
L <byte size> - Local byte Byte size
Domyślnym typem reprezentacji jest ASCII Non-print. Jeżeli parametr „Format” nie jest zmieniony, a później zmieniany jest tylko pierwszy argument, „Format” powraca do domyślnego „Non-print”.
FILE STRUCTURE (STRU)
Argumentem jest pojedynczy znak zgodny z Telnet określający strukturę pliku (opisaną w Reprezentacji Danych i Przechowywania, Data Representation and Storage).
Struktura jest opisywana przez następujące kody:
F - Plik - brak struktury rekordu (File)
R - Struktura rekordu (Record structure)
P - Struktura strony (Page structure)
Domyślne jest File.
TRANSFER MODE (MODE)
Argumentem jest pojedynczy znak zgodny z Telnet określający tryby transferu opisane w rozdziale Tryby Transmisji, Transmission Modes.
Tryb transferu jest opisywany przez następujące kody:
S - Stream
B - Block
C - Compressed
Domyślny jest Stream.
1.2.3. Polecenia usług FTP
Te polecenia FTP definiują transfer pliku lub funkcje systemu plików wymagane przez użytkownika. Argument polecenia usług zazwyczaj jest ścieżka. Składnia ścieżki musi zgadzać się z konwencją stosowaną przez serwer (z zastosowaniem standardowych wartości domyślnych) i konwencjami językowymi dla kontroli połączenia. Sugerowaną wartością domyślna jest używanie ostatniego określonego urządzenia, katalogu lub nazwy pliku lub standardowej wartości dla lokalnego użytkownika. Polecenia mogą być stosowane w dowolnej kolejności, z wyjątkiem polecenia „rename from”, po którym musi następować „rename to” i polecenia „restart”, po którym musu nastąpić „przerwane” polecenie usługi (np. STOR albo RETR). Dane podczas transferu w odpowiedzi na polecenie usługi FTP powinny być zawsze przesyłane przez połączenie danych (nie połączenie kontrolne) z wyjątkiem pewnych odpowiedzi niosących informację. Poniżej podane określają żądania usług FTP:
RETRIEVE (RETR)
To polecenie powoduje, że serwer przesyła kopię pliku, określonego przez ścieżkę do komputera klienta. Status i zawartość pliku po stronie serwera nie powinny podlegać żadnym wpływom.
STORE (STOR)
Polecenie powoduje, że serwer akceptuje przesłane dane jako plik. Jeżeli plik określony przez ścieżkę istnieje po stronie serwera, jego zawartość powinna zostać zastąpiona przez przesyłane dane. Jeżeli podana ścieżka nie istnieje, zostaje utworzony nowy plik.
PRZECHOWAJ UNIKATOWY (STOU)
Polecenie zachowuje się jak STOR, z wyjątkiem tego, że powstały plik ma zostać utworzony w bieżącym katalogu pod nazwą unikatową w katalogu. Odpowiedź 250 Transfer Started musi zawierać nawę utworzonego pliku.
APPEND (wraz z utwórz) (APPE)
Powoduje, że serwer przyjmuje dane przesyłane przez połączenie danych i zachowuje je w pliku. Jeżeli plik określony przez ścieżkę istnieje po stronie serwera, dane powinny zostać dołączone do pliku, w przeciwnym przypadku powinien zostać utworzony.
ALLOCATE (ALLO)
Polecenie może być wymagane przez niektóre serwery w celu zarezerwowania odpowiedniej ilości „miejsca” do przechowywania przesyłanego pliku. Argument powinien być całkowitą liczbą dziesiętną odzwierciedlającą liczbę bajtów (używając logicznej wielkości bajtu) dla miejsca zarezerwowanego do przechowania pliku. Dla plików o strukturze rekordu albo struktury może być także konieczne określenie maksymalnej wielkości rekordu/struktury, co określa drugi argument polecenia. Jest on opcjonalny, jednak kiedy się go podaje, powinien być oddzielony od pierwszego trzema znakami telnetowymi: <SP> R <SP>. Po poleceniu powinno nastąpić STOR albo APPE. Polecenie ALLO powinno być traktowane jako NOOP (no operation - brak działania) przez serwery, które nie wymagają uprzedniej deklaracji maksymalnej wielkości pliku, a te serwery które interesuje jedynie maksymalny rozmiar rekordu/strony powinny przyjmować dowolną wartość pierwszego argumentu i ignorować go.
RESTART (REST)
Pole argumentu określa marker serwera, na którym transfer pliku ma zostać wznowiony. Polecenie nie powoduje transferu pliku, natomiast przeskakuje przez cały plik do wskazanego punktu danych. Polecenie powinno natychmiast pociągnąć za sobą odpowiednie polecenie usługi FTP, które powinno wznowić transfer pliku.
RENAME FROM (RNFR)
Określa starą ścieżke pliku, którego nazwa ma zostać zmieniona. Po poleceniu natychmiast powinno nastąpić RNTO określające nową ścieżkę pliku.
RENAME TO (RNTO)
Określa nową ścieżkę pliku określonego w wykonanym przed chwilą poleceniu RNFR. Te dwie komendy są używane do zmiany nazwy pliku.
ABORT (ABOR)
Polecenie mówi serwerowi, żeby porzucił poprzednią usługę FTP i każdym powiązanym transferem danych. Polecenie ABOR może wymagać „specjalnych czynności”, jak opisane w rozdziale Polecenia FTP, FTP Commands, w celu wymuszenia rozpoznania go przez serwer. Polecenie nie powinno wywołać żadnej akcji, jeżeli poprzednie polecenie (włączając transfer danych) zostało zakończone. Połączenie kontrolne nie powinno ulec zamknięciu, dotyczy to tylko połączenia danych.
Istnieją dwa przypadki potwierdzania tego polecenia: (1) usługa FTP już została zakończona, (2) wykonywanie usługi FTP wciąż trwa. W pierwszym przypadku, serwer zamyka połączenie danych (jeżeli jest otwarte) i odpowiada odpowiedzią o kodzie 226 wskazującą poprawne wykonanie polecenia ABORT. W drugim przypadku serwer porzuca trwającą usługę FTP i zamyka połączenie danych, zwracając odpowiedź 426 wskazującą „nienormalne” zakończenie usługi.. następnie serwer wysyła odpowiedź 226, mówiącą o prawidłowym wykonaniu polecenia ABOR.
DELETE (DELE)
Polecenie powoduje usunięcie pliku określonego przez ścieżkę po stronie serwera. Jeżeli wymagany jest dodatkowy poziom zabezpieczenia (np. „Czy na pewno chcesz usunąć…?”), powinien on być zapewniony po stronie użytkownika.
REMOVE DIRECTORY (RMD)
Powoduje usunięcie katalogu określonego przez ścieżkę (względną lub absolutną) po stronie serwera.
MAKE DIRECTORY (MKD)
Polecenie tworzy catalog określony przez ścieżkę (względną lub absolutną) po stronie serwera.
PRINT WORKING DIRECTORY (PWD)
Wyświetla nazwę bieżącego katalogu na zdalnej maszynie.
LIST (LIST)
Powoduje wysłanie listy z serwera do pasywnego DTP. Jeżeli ścieżka określa katalog lub grupę plików, serwer powinien wysłać listę plików w określonym katalogu. Jeżeli ścieżka określa plik,, serwer powinien przesłać informację o pliku. Posty argument wskazuje bieżący katalog użytkownika. Transfer danych odbywa się przez połączenie danych w formie ASCII albo EBCDIC (użytkownik musi upewnić się, że TYPE jest ustawione prawidłowo na ASCII albo EBCDIC). Ponieważ informacja o pliku może różnić się zależnie od systemu, może być trudna do automatycznego wykorzystania przez program, ale może być całkiem użyteczna dla człowieka.
NAME LIST (NLST)
Powoduje wysłanie z serwera listingu katalogu. Ścieżka powinna określać katalog albo inny zależny od systemu deskryptor grupy plików, pusty argument wskazuje bieżący katalog. Serwer zwraca ciąg nazw plików bez dodatkowej informacji. Ponownie, transfer danych odbywa się przez połączenie danych w formie ASCII albo EBCDIC (użytkownik musi upewnić się, że TYPE jest ustawione prawidłowo na ASCII albo EBCDIC), gdzie poszczególne nazwy są oddzielone przez <CRLF> or <NL>. Polecenie ma na celu zwracanie informacji, która może być użyteczna dla programu w celu dalszego automatycznego przetwarzania plików, np. w implementacji metody „multiple get”.
SITE PARAMETERS (SITE)
Polecenie jest wykorzystywane przez serwer do zapewnienia specyficznych dla jego systemu usług, które są niezbędne dla transferu plików, jednak niedostatecznie uniwersalne, żeby je włączyć jako polecenia protokołu. Natura tych usług i określenie składni może być zawarte w odpowiedzi na polecenie HELP SITE.
SYSTEM (SYST)
Polecenie jest wykorzystywane w celu odnalezienia rodzaju systemu operacyjnego serwera. Odpowiedź zawiera jako pierwsze słowo jedną z nazw systemu określonych w Assigned Numbers Document.
STATUS (STAT)
Polecenie powoduje odpowiedź dotyczącą statusu (wysyłaną przez połączenie kontrolne). Polecenie może być przesłane podczas transferu pliku (razem z sygnałami Telnet IP i Synch - zob. rozdział FTP Commands), w którym przypadku serwer odpowie stanem postępu operacji. Może tez być wysłane pomiędzy transferami plików. W takim przypadku polecenie może zawierać pole argumentu. Jeżeli argument jest ścieżką, polecenie jest analogiczne do LIST, z wyjątkiem tego, że dane są przesyłane przez połączenie kontrolne. Jeżeli podana jest częściowa ścieżka, serwer może odpowiedzieć listą odpowiednich nazw lub atrybutów. W przypadku braku argumentów, serwer zwraca ogólną informację o stanie procesu serwera FTP. Powinna zawierać bieżące wartości parametrów transferu i stanu połączenia.
HELP (HELP)
Polecenie powoduje, że serwer zwraca pomocne informacje dotyczące jego implementacji przez połączenie kontrolne. Polecenie może przyjmować jako argument nazwę innego polecenia i zwracać bardziej szczegółowy jej opis. Typ odpowiedzi jest 211 lub 214. Zaleca się, że HELP może być stosowane przed poleceniem USER. Serwer może wykorzystywać to polecenie w celu określenia specyficznych dla strony parametrów, np. w odpowiedzi na HELP SITE.
NOOP (NOOP)
Polecenie to nie ma wpływu na żadne parametry, ani poprzednio wprowadzone komendy. Nie określa żadnej akcji z wyjątkiem wysłania przez serwer odpowiedzi OK.
1.2.4. Odpowiedzi FTP
Odpowiedzi na polecenia FTP są stosowane w celu zapewnienia synchronizacji żądań i akcji w procesie przesyłania plików oraz żeby zapewnienia, że proces użytkownika zawsze zna stan serwera. Każde polecenie powoduje co najmniej jedną odpowiedź, chociaż niektóre mogą wywoływać wielokrotne odpowiedzi. W takim przypadku muszą one być łatwo rozróżnialne. Dodatkowo, niektóre polecenia pojawiają się w sekwencyjnych grupach (np. USER, PASS i ACCT lub RNFR i RNTO). Odpowiedź pokazuje istnienie pośredniego stanu, jeżeli wszystkie poprzedzające polecenia zostały wykonane poprawnie. Błąd w dowolnym punkcie takiej sekwencji wymusza powtórzenie całej sekwencji od początku.
Odpowiedź FTP składa się z trzech cyfr (przesyłanych jako trzy znaki alfanumeryczne), po których następuje tekst. Liczba ma zastosowanie w automatycznej obsłudze procesów do określania, w który stan należy następnie wejść, tekst jest przeznaczony dla ludzkiego użytkownika. Trzy cyfry powinny zawierać dostatecznie dużo informacji, że proces użytkownika nie będzie potrzebował sprawdzać tekstu i mógł albo zignorować albo przesłać informację dalej użytkownikowi, zależnie co jest w danej sytuacji odpowiednie. W szczególności, tekst informacji może zależeć od samego serwera, także istnieje prawdopodobieństwo, że będą się od siebie różnić przy identycznych kodach odpowiedzi.
Odpowiedź jest zdefiniowana jako 3-cyforwy kod, po którym następuje spacja <SP>, dalej jedna linia tekstu (o określonej maksymalnej długości). Zakończeniem linii jest telnetowy znak końca linii (end-of-line). Mogą się jednak pojawić przypadki, w których tekst jest dłuższy niż pojedyncza linia. Wtedy cały tekst informacji musi być ujęty w nawiasy, żeby proces użytkownika wiedział w którym miejscu przestać czytać odpowiedź (np. przestać przetwarzać wejście połączenia kontrolnego) i przejść do wykonywania dalszych czynności. Wymaga to specjalnego formatu w pierwszej linii, który wskazuje, że nadchodzi więcej niż jedna linia oraz innego w ostatniej dla jej wyróżnienia. Przynajmniej jedna z nich musi zawierać poprawny kod odpowiedzi dla wskazania stanu transakcji. W celu spełnienia wszystkich wymogów, zadecydowano że pierwsza i ostatnia linia powinny być takie same.
Dlatego format „wieloliniowych” odpowiedzi jest taki, że pierwsza linia zaczyna się wymaganym kodem odpowiedzi, następna myślnikiem (minusem) „-”, po którym następuje tekst. Ostatnia linia zaczyna się tym samym kodem, po którym pojawia się <SP>, względnie jakiś tekst i zgodny z tekstem znak końca linii.
Przykład:
123-First line
Second line
234 A line beginning with numbers
123 The last line
Proces użytkownika potrzebuje po prostu wyszukać kolejne wystąpienie tego samego kodu odpowiedzi, po którym występuje spacja na początku linii, ignorując linie pomiędzy. Jeżeli któraś z linii w środku zaczyna się 3-cyfrową liczbą, serwer musi dodać na jej początku wcięcie dla wyeliminowania pomyłek.
Nie dopuszcza się zagnieżdżania wieloliniowych odpowiedzi.
Każda z trzech cyfr odpowiedzi posiada swoje znaczenie. Założeniem jest dopuszczenie zakresu od bardzo prostych do bardzo skomplikowany odpowiedzi przez proces użytkownika. Pierwsza cyfra określa, czy odpowiedź jest pozytywna, negatywna, czy niekompletna. Odnosząc się do diagramu stanów prosty proces użytkownika może określić następne działanie (postępować zgodnie z planem, ponowić działanie, itp.) poprzez zwykłe sprawdzenie pierwszej cyfry. Proces użytkownika, który chce w przybliżeniu określić, jaki rodzaj błędu miał miejsce (np. błąd systemu plików, błąd składni polecenia) może sprawdzić drugą cyfrę, zachowując trzecią cyfrę dla najbardziej szczegółowej informacji (np. RNTO bez poprzedzającego RNFR).
Pierwsza cyfra odpowiedzi może przyjmować pięć wartości:
1yz pozytywna odpowiedź wstępna
Żądana akcja jest rozpoczynana, oczekuj kolejnej odpowiedzi przed wysyłaniem kolejnego polecenia (proces użytkownika wysyłający kolejne polecenia przed dokończeniem odpowiedzi kłóciłby się z protokołem, ale proces serwera FTP powinien kolejkować wszystkie polecenia przychodzące podczas wykonywania poprzedniego polecenia). Ten typ odpowiedzi może być wykorzystywany dl wskazania, że komenda została przyjęta i proces użytkownika może skoncentrować się na połączeniu danych przy implementacjach, gdzie równoczesne monitorowanie może być trudne. Proces serwera FTP może wysłać maksymalnie jedną odpowiedź 1yz na polecenie.
2yz odpowiedź pozytywnego ukończenia
Żądana akcja została prawidłowo wykonana. Można rozpoczynać kolejne żądania.
3yz pozytywna odpowiedź pośrednia
Polecenie zostało przyjęcie, jednak żądana akcja jest wstrzymana czekając na dalsze informacje. Użytkownik powinien wysłać kolejne polecenie określające tą informację. Odpowiedź jest stosowana w sekwencyjnych grupach poleceń.
4yz przejściowa odpowiedź negatywnego ukończenia
Polecenie nie zostało przyjęte i żądana akcja nie miała miejsca, ale przyczyna błędu jest tymczasowa i można żądać akcji później. Użytkownik powinien powrócić do początku sekwencji komend, jeżeli ją wykorzystywał. Trudno jest przypisać znaczenie słowu „przejściowa”, szczególnie kiedy 2 konkretne strony (proces serwera i użytkownika) muszą uzgodnić jego interpretację. Każda odpowiedź w kategorii 4yz może mieć nieznacznie różną wartość czasową, jednak intencją jest zachęcenie procesu użytkownika do ponowienia ostatniej komendy (ciągu komend). Przyjmuje się, że jeżeli odpowiedź pasuje to kategorii 4xy albo 5yz (trwale negatywna), 4yz stosuje się do poleceń, które mogą być powtórzone bez żadnych zmian formy ani właściwości polecenia po stronie użytkownika ani serwera. (komenda napisana w ten sam sposób, z tymi samymi argumentami, użytkownik nie zmienia nazwy ani praw dostępu, serwer nie przedstawia nowej implementacji).
5yz trwała odpowiedź negatywnego ukończenia
Polecenie nie zostało zaakceptowane i żądana akcja nie miała miejsca. Proces użytkownika nie powinien powtarzać dokładnie tego samego polecenia (w tej samej sekwencji). Nawet niektóre „trwałe” błędy można poprawić, także ludzki użytkownik może chcieć pokierować procesem użytkownika w celu odnowienia ciągu poleceń przez proste działanie gdzieś w przyszłości (np. po zmianie pisowni albo stanu katalogów).
Poniżej jest zaprezentowane funkcjonalne grupowanie poprzez drugą cyfrę.
x0z składnia
Odpowiedź dotyczy błędy składniowego, syntaktycznie poprawne polecenia nie odpowiadają żadnej funkcjonalnej kategorii, komenda niezaimplementowana.
x1z informacja
Te odpowiedzi dotyczą żądań informacji, np. stanu albo pomocy.
x2z połączenia
Odpowiedzi odnoszą się do połączenia kontrolnego i połączenia danych.
x3z Authentication and accounting
Odpowiedzi na process logowania i procedury określania uprawnień.
x4z
Obecnie niezdefiniowane.
x5z File system
Odpowiedzi wskazują stan systemu plików serwera względem żądanego transferu i innych operacji na plikach.
Trzecia cyfra daje najbardziej szczegółowe znaczenie każdej z funkcjonalnych kategorii, określonych przez drugą cyfrę. Ilustruje to poniższa lista odpowiedzi. Proszę zauważyć, że tekst powiązany z każdą odpowiedzią jest raczej formą zalecaną niż wymaganą i może zmieniać się zależnie od polecenia, z którym jest związany. Z drugiej strony, kody odpowiedzi muszą ściśle przestrzegać specyfikacji, tzn. implementacje serwera nie powinny wprowadzać nowych kodów w sytuacjach tylko lekko różniących się od opisanych tutaj. Powinny raczej adoptować już zdefiniowane kody.
Polecenie w rodzaju TYPE albo ALLO po poprawnym wykonaniu nie oferuje procesowi użytkownika żadnej nowej informacji, dlatego wywołuje odpowiedź 200. Jeżeli polecenie nie jest zaimplementowane przez konkretny proces serwera FTP ponieważ nie ma odniesienia do systemu plików serwera, np. ALLO na stronie TOPS20, odpowiedź pozytywnego ukończenia jest wciąż na miejscu, tak aby prosty proces użytkownika mógł przeprowadzać kolejne działania. Odpowiedź 202 jest wykorzystywana w tym momencie z przykładowym tekstem odpowiedzi „Brak potrzeby alokacji miejsca przechowywania” (No storage allocation necessary). Jeżeli, z drugiej strony, polecenie żąda akcji niezwiązanej ze specyfiką strony, a jest niezaimplementowane, pojawia się odpowiedź 502. Uszczegółowieniem tej odpowiedzi jest 504 - polecenie zaimplementowane, ale żąda niezaimplementowanego parametru.
Kody odpowiedzi według grup funkcjonalnych
200 Command okay.
500 Syntax error, command unrecognized.
This may include errors such as command line too long.
501 Syntax error in parameters or arguments.
202 Command not implemented, superfluous at this site.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
110 Restart marker reply.
In this case, the text is exact and not left to the
particular implementation; it must read:
MARK yyyy = mmmm
Where yyyy is User-process data stream marker, and mmmm
server's equivalent marker (note the spaces between markers
and "=").
211 System status, or system help reply.
212 Directory status.
213 File status.
214 Help message.
On how to use the server or the meaning of a particular
non-standard command. This reply is useful only to the
human user.
215 NAME system type.
Where NAME is an official system name from the list in the
Assigned Numbers document.
120 Service ready in nnn minutes.
220 Service ready for new user.
221 Service closing control connection.
Logged out if appropriate.
421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down.
125 Data connection already open; transfer starting.
225 Data connection open; no transfer in progress.
425 Can't open data connection.
226 Closing data connection.
Requested file action successful (for example, file
transfer or file abort).
426 Connection closed; transfer aborted.
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
230 User logged in, proceed.
530 Not logged in.
331 User name okay, need password.
332 Need account for login.
532 Need account for storing files.
150 File status okay; about to open data connection.
250 Requested file action okay, completed.
257 "PATHNAME" created.
350 Requested file action pending further information.
450 Requested file action not taken.
File unavailable (e.g., file busy).
550 Requested action not taken.
File unavailable (e.g., file not found, no access).
451 Requested action aborted. Local error in processing.
551 Requested action aborted. Page type unknown.
452 Requested action not taken.
Insufficient storage space in system.
552 Requested file action aborted.
Exceeded storage allocation (for current directory or
dataset).
553 Requested action not taken.
File name not allowed.
Numeryczna kolejność kodów odpowiedzi
110 Restart marker reply.
In this case, the text is exact and not left to the
particular implementation; it must read:
MARK yyyy = mmmm
Where yyyy is User-process data stream marker, and mmmm
server's equivalent marker (note the spaces between markers
and "=").
120 Service ready in nnn minutes.
125 Data connection already open; transfer starting.
150 File status okay; about to open data connection.
200 Command okay.
202 Command not implemented, superfluous at this site.
211 System status, or system help reply.
212 Directory status.
213 File status.
214 Help message.
On how to use the server or the meaning of a particular
non-standard command. This reply is useful only to the
human user.
215 NAME system type.
Where NAME is an official system name from the list in the
Assigned Numbers document.
220 Service ready for new user.
221 Service closing control connection.
Logged out if appropriate.
225 Data connection open; no transfer in progress.
226 Closing data connection.
Requested file action successful (for example, file
transfer or file abort).
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
230 User logged in, proceed.
250 Requested file action okay, completed.
257 "PATHNAME" created.
331 User name okay, need password.
332 Need account for login.
350 Requested file action pending further information.
421 Service not available, closing control connection.
This may be a reply to any command if the service knows it
must shut down.
425 Can't open data connection.
426 Connection closed; transfer aborted.
450 Requested file action not taken.
File unavailable (e.g., file busy).
451 Requested action aborted: local error in processing.
452 Requested action not taken.
Insufficient storage space in system.
500 Syntax error, command unrecognized.
This may include errors such as command line too long.
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
530 Not logged in.
532 Need account for storing files.
550 Requested action not taken.
File unavailable (e.g., file not found, no access).
551 Requested action aborted: page type unknown.
552 Requested file action aborted.
Exceeded storage allocation (for current directory or
dataset).
553 Requested action not taken.
File name not allowed.
Więcej na temat poleceń i mechanizmów FTP można znaleźć na stronie w stopce.
1.3. Przykładowe sesje FTP
1.3.1. Sesja anonimowa
% ftp cs.colorado.edu
Connected to cs.colorado.edu.
220 bruno FTP server (SunOS 4.1) ready.
Name (cs.colorado.edu:yourlogin): anonymous
331 Guest login ok, send ident as password.
Password:
230-This server is courtesy of Sun Microsystems, Inc.
230-
230-The data on this FTP server can be searched and accessed via WAIS, using
230-our Essence semantic indexing system. Users can pick up a copy of the
230-WAIS ".src" file for accessing this service by anonymous FTP from
230-ftp.cs.colorado.edu, in pub/cs/distribs/essence/aftp-cs-colorado-edu.src
230-This file also describes where to get the prototype source code and a
230-paper about this system.
230-
230-
230 Guest login ok, access restrictions apply.
ftp> cd /pub/HPSC
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 ASCII data connection for /bin/ls (128.138.242.10,3133) (0 bytes).
ElementsofAVS.ps.Z
. . .
execsumm_tr.ps.Z
viShortRef.ps.Z
226 ASCII Transfer complete.
418 bytes received in 0.043 seconds (9.5 Kbytes/s)
ftp> get README
200 PORT command successful.
150 ASCII data connection for README (128.138.242.10,3134) (2881 bytes).
226 ASCII Transfer complete.
local: README remote: README
2939 bytes received in 0.066 seconds (43 Kbytes/s)
ftp> bye
221 Goodbye.
% ls
1.3.1. Sesja regularna
% ftp nordsieck.cs.colorado.edu
Connected to nordsieck.cs.colorado.edu.
220 nordsieck FTP server (Version 5.53 Tue Aug 25 10:46:12 MDT 1992) ready.
Name (nordsieck.cs.colorado.edu:yourlogin): yourlogin
331 Password required for yourlogin.
Password:
230 User yourlogin logged in.
ftp> cd HPSC/exercises
250 CWD command successful.
ftp> ls
200 PORT command successful.
550 No files found.
ftp> put tmul.out
200 PORT command successful.
150 Opening ASCII mode data connection for tmul.out.
226 Transfer complete.
local: tmul.out remote: tmul.out
1882 bytes sent in 0.0095 seconds (1.9e+02 Kbytes/s)
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
tmul.out
226 Transfer complete.
9 bytes received in 0.0021 seconds (4.3 Kbytes/s)
ftp> mput *
mput Makefile? y
200 PORT command successful.
150 Opening ASCII mode data connection for Makefile.
226 Transfer complete.
local: Makefile remote: Makefile
1020 bytes sent in 0.0062 seconds (1.6e+02 Kbytes/s)
mput tmul.out? n
ftp> quit
221 Goodbye.
% ls
. . .
Makefile
tmul.out
Sieci komputerowe, lab. 3 |
studia uzupełniające magisterskie (zaoczne) |
1 |