Zasady transmisji danych za pomocą protokołu FTP 1. Gdy obie

Edinet – Zasady transmisji danych za pomocą protokołu FTP

13-12-2006

Zasady transmisji danych za pomocą protokołu FTP 1. Gdy obie strony transmisji dysponuja swoimi serwerami, strona wysyłająca komunikat jest odpowiedzialna za przesyłkę przez internet. Strona odbierająca monitoruje - oczekując na komunikat - tylko konta lokalne. Daje to następujace korzyści: a) zmiejszenie obciążenia sieci - listujemy tylko katalogi na lokalnym serwerze FTP b) szybsza reakcja na potencjalne problemy z łączem - nieudane próby wysłania dokumentu stanowią czytelną informację o problemach z łączem c) wysoka pewność dostarczenia plików W przypadku, gdy druga strona transmisji nie jest w stanie zapewnić stabilnego konta FTP dostępnego przez dobre łącza internetowe zalecamy wysyłanie i odbieranie dokumentów z konta FTP firmy Infinite. 2. Należy przyjąć, że w ogólnej sytuacji na serwerze FTP dokument jest widziany już tuż po przesłaniu pierwszych bajtów, zanim jego transmisja dobiegnie końca. Aspekt ten wynika z zamierzonej specyfiki protokołu FTP. Oczywiście niektóre serwery FTP można skonfigurować tak by pliki będące w trakcie transmisji nie były widoczne na koncie, lecz to nie rozwiązuje wszystkich problemów; widoczne będą pliki, których transmisja została przerwana. Zatem wymagane jest stosowanie mechanizmów zabezpieczających przed przedwczesną obsługa pliku, dlatego też wprowadziliśmy pewne zasady weryfikacji transmisji. Możliwe są dwa podejścia: a) Przez przemianowanie pliku tymczasowego na plik docelowy. Polecenie zmiany nazwy jest atomowe, zatem możemy je z powodzeniem wykorzystywać jako potwierdzenie końca transmisji. Transmisję pliku dokonujemy do podkatalogu temp docelowego katalogu, a następnie po prawidłowym zakończeniu transmisji zmieniamy nazwę pliku na nazwę właściwą zmieniając także katalog: b) RNFR example.xml 350 File or directory exists, ready for destination name. RNTO ../example.xml 250 rename successful.

c) Przez dodatkowy plik diagnostyczny. Każda poprawna transmisja dokumentu jest potwierdzana utworzeniem pliku diagnostycznego o nazwie składającej sie z nazwy pliku właściwego z doklejonym na końcu przyrostkiem ".ok", np. dla pliku "faktura.xml" tworzymy plik diagnostyczny "faktura.xml.ok". Uwaga, ważna jest wielkość liter, ".ok" piszemy małymi literami a resztę przepisujemy z taką samą wielkością znaków z nazwy pliku właściwego. Jeżeli stytem uniemożliwia tworzenie plików z wieloma kropkami to plik właściwy nazywamy bez rozszerzenia tak by plik diagnostyczny miał tylko jedną kropkę, np. "faktura" i "faktura.ok". Taki plik diagnostyczny może mieć rozmiar zerowy, ale może także zawierać informacje diagnostyczne (np. sumę kontrolną). Odbieranie pliku powinno zatem być poprzedzone testem istnienia pliku diagnostycznego, co zagwarantuje, że transmisja pliku właściwego dobiegła do końca (a nie została zerwana np. przez usterki połączenia sieciowego).

1z2 Signature Not Verified Digitally signed by Infinite Sp. z o.o. Date: 2006.12.13 16:15:58 CET Reason: I'm the author Location: Poland, Lublin

Edinet – Zasady transmisji danych za pomocą protokołu FTP

13-12-2006

Należy dodać, że operacje te stanowią uzupełnienie, majace na celu przekszatłcenie nietransakcyjnego protokołu FTP na protokół transakcyjny. Kolejnym niedostatkiem jest bezpieczeństwo, standardowo FTP nie ma szyfrowania, dostępne jest ono dopiero w kilku rozszerzeniach tego protokołu. Dzisiaj są już protokoły, które projektowane były z założeniem obsługi tych aspektów. Takim protokołem zyskujacym coraz większą popularność jest AS2, ma on także szereg innych zalet i warto go rozważyć jako alternatywę względem FTP. 3. Reakcja na błędy. Nierozłączną konsekwencją odbioru komunikatu powinno być wygenerowanie komunikatu potwierdzenia prawidłowego odbioru lub błędu oraz wysłanie tych komunikatów na serwer zdalny. Postać tych komunikatów jest umowna, ale warto stosować tutaj standardy do zarządzania wiadomościami z xCBL: MessageAcknowledgement, ApplicationResponse oraz ErrorResponse (więcej informacji: http://www.xcbl.org/xcbl40/xcbl40.shtml i tutaj http://www.infinite.pl/pub/doc/fmt/xml/msgmanagement/ ). Strona stwierdzająca błąd i wysyłająca komunikat błędu jest zobowiązana do wszczęcia procedury mającej na celu usunięcie przyczyn błędu. Strona odbierająca komunikat o błędzie może - lecz nie musi bez wyraźnej prośby strony nadającej błąd - zająć się usunięciem przyczyn tego błędu. 4. Archiwizacja komunikatów. Każda strona zajmuje się cykliczną archiwizacją pozostawionych na serwerze kopii przetworzonych komunikatów. Cykl nie powinien być częstszy niż 1 dzień, a preferowany interwał to 1 miesiąc.

2z2