Wybrane protokoły aplikacyjne TCP/IP DSTP, NTP, PTP, RPC, VXI-11

DataSocket Transfer Protocol (DSTP) DataSocket jest technologią programistyczną opracowaną przez firmę National Instruments w celu uproszczenia i poprawy efektywności procesu projektowania aplikacji realizujących akwizycję i przesyłanie danych w rozproszonych systemach pomiarowych opartych na internetowym protokole komunikacyjnym TCP/IP.

Komponenty DataSocket W protokole DataSocket wyróżnić można dwa komponenty: - DataSocket API, - Datasocket Server.

Współdzielenie danych pomiarowych

DataSocket API kontrolka ActiveX, biblioteka w języku C dla LabWindows/CVI, zestaw programów środowiska LabView – VI, biblioteka do języka Java ?

Operacje DataSocket API Open Read Write Close

Nadawanie danych Wymagana jest współpraca 3 elementów: - nadawcy (publisher, lub writer), - serwera DataSocket, - abonenta (subscriber, lub reader). Lokalizację nadawcy oraz uprawnienia klientów określa się za pomocą narzędzia: DataSocket Server Manager.

Synchronizacja czasu NTP (A. Puzio)

Network Time Protocol - NTP Protokół NTP jest protokołem umożliwiającym synchronizację czasową wielu urządzeń pracujących w sieci TCP/IP, który został opracowany przez David L. Mills’a, profesora Uniwersytetu w Delaware. Pierwsze implementacje protokołu powstały w 1980 r. i były one nazywane jako Internet Clock Service [1], jednakże protokół NTP po raz pierwszy został opisany w 1988 roku [2].

NTP wytwarza 3 informacje: Offset (wartość czasu do skorygowania) Opóźnienie (związane z transportem wiadomości) Dyspersję (szacunek błędu lokalnego zegara w stosunku do zegara odniesienia)

Cechy podstawowe Dane przenoszone przez IP i UDP (możliwość stosowania rozgłaszania grupowego ma znaczenie przy pracy z wieloma klientami) Klient wysyła zapytania do kilku serwerów, otrzymane odpowiedzi analizuje i wybiera najbardziej odpowiedni (precyzja, odległość) (Best Master Clock). Po wyborze klient synchronizuje swój zegar.

Schemat wymiany wiadomości NTP

Legenda T1 – klient wysyła wiadomość do serwera T2 – serwer rejestruje odbiór wiadomości T3 – serwer wyznacza czas odesłania wiadomośći T4- moment dotarcia odpowiedzi

Obliczenie offset’u

(Precision Time Protocol) Protokół PTP (Precision Time Protocol)

PTP Precision Time Protocol jest najnowszym standardem synchronizacji czasu w sieciach komputerowych, mającym na celu zwiększenie precyzji synchronizacji czasowej. Protokół ten został opracowany przez firmę Agilent w celu kontroli zadań w różnych urządzeniach, za szczególnym naciskiem na rozproszone pomiary.

Koncepcja PTP W przeciwieństwie do protokołu NTP, znaczniki czasu zawierające informacje o nim nie są transmitowane w synchronizujących pakietach, ale dopiero w paczkach następujących po nich. W ten sposób pomiar czasu wysyłanych i odbieranych wiadomości może być oddzielony od transmisji uzyskanych informacji o tym czasie. Na podstawie uzyskanych znaczników czasowych wyznaczane są dwie informacje: opóźnienie i offset.

Opóźnienie i offset Opóźnienie jest to czas, jaki jest potrzebny na transmisję wiadomości PTP z jednego urządzenia do drugiego, natomiast offset jest to różnica czasu pomiędzy zegarami danych urządzeń, o którą należy zsynchronizować urządzenie pracujące jako podrzędne. Opóźnienie jest wyznaczane, co jakiś określony czas (rzadziej aniżeli offset) i stanowi ono podstawę do obliczania offsetu.

Wsparcie sprzętowe! Jedną z najważniejszych cech protokołu PTP jest zastosowanie dla niego wsparcia sprzętowego, dzięki któremu istnieje możliwość wyeliminowania opóźnień związanych z transmisją danych od karty sieciowej danego urządzenia do jego jednostki obliczeniowej. Zakłada się wyeliminowanie przede wszystkim opóźnień związanych ze stosem protokołu sieciowego, a także wyeliminowanie wpływu obciążenia jednostki obliczeniowej danego urządzenia na szybkość tej transmisji. Podejście to zakłada uzyskiwanie znaczników czasowych na poziomie sprzętowym, a nie programowym jak to jest na przykład w NTP.

Master- slave model Synchronizacja czasu za pomocą PTP polega na wymianie wiadomości pomiędzy dwoma urządzeniami, gdzie jedno z urządzeń jest synchronizowane (slave), a drugie jest dostarczycielem czasu i synchronizuje to pierwsze (master).

Synchronizacja czasu

Obliczenie offset’u Offset obliczany jest ze wzoru : offset = TM_SS1 – TS_SR1 – delay - TM_SS1 (Time Master Sync Send) – czas, w którym urządzenie synchronizujące wysłało wiadomość Sync, - TS_SR1 (Time Slave Sync Recept) – czas, odbioru wiadomości Sync przez urządzenie synchronizowane, delay – opóźnienie wynikające z czasu transmisji wiadomości. na razie offset jest równy 0 offset = TM_SS1 – TS_SR1 -0

2 faza synchronizacji Początkiem drugiej fazy jest wysłanie przez slave’a wiadomości nazywanej zapytaniem o opóźnienie, czyli Delay_req, do urządzenia synchronizującego. W czasie tego procesu określany jest dokładny czas transmisji tej wiadomości, a mianowicie slave wyznacza i zapamiętuje dokładny czas (TS_RS) wysłania zapytania o opóźnienie, natomiast master określa dokładny czas odbioru tej wiadomości (TM_RR). Kolejnym krokiem jest wysłanie przez master’a wiadomości Delay_resp będącej odpowiedzią na poprzednią wiadomość i zawierającą dokładną wartość czasu odbioru zapytania o opóźnienia (TM_RR). Wiadomość Delay_resp jest odbierana przez urządzenie synchronizowane, które to na podstawie poniższego wzoru (3.3.) oblicza opóźnienie. delay = ((TS_SR2- TM_SS2) + (TM_RR – TS_RS)) / 2 (3.3.) ,gdzie: - TM_SS2 (Time Master Sync Send) – czas, w którym urządzenie synchronizujące wysłało wiadomość Sync, - TS_SR2 (Time Slave Sync Recept) – czas, odbioru wiadomości Sync przez urządzenie synchronizowane po wstępnej korekcji zegara, - TM_RR (Time Master Request Receipt) – czas, w którym urządzenie synchronizujące odebrało wiadomość Delay_req po wstępnej korekcji zegara, - TS_RS (Time Slave Request Send) – czas, wysłania wiadomości Delay_req przez urządzenie synchronizowane. Teraz jest już znana wartość czasu trwania transmisji wiadomości pomiędzy danymi urządzeniami, wobec tego przeprowadzana jest ponownie transmisja wiadomości Sync w czasie, której określane zostają czasy: wysłania tej wiadomości przez urządzenie nadrzędne (TM_SS3) i czasu odbioru tej wiadomości (TS_SR3) przez urządzenie mu podległe, czyli synchronizowane. Następnie przesyłana jest wiadomość Follow_up do slave’a, który to oblicza offset ze wzoru (3.4.) poniżej. offset = TM_SS3 – TS_SR3 – delay (3.4.) Wyliczony czas stanowi wartość, o jaką urządzenie synchronizowane koryguje swój zegar w wyniku, czego uzyskujemy synchronizację omawianych urządzeń. Następnie proces ten jest powtarzany, przy czym teraz znane jest już opóźnienie. Opóźnienie to nie ulega gwałtownym zmianom, w związku, z czym, wymiana wiadomości Delay_req i Delay_resp odbywa się zazwyczaj około 10 razy rzadziej aniżeli wysyłanie wiadomości Sync i Follow_up, które są wysyłane przez master’a w sposób synchroniczny (np. co 2 sekundy).

Porównanie protokół NTP służy do synchronizacji czasowej urządzeń względem czasu rzeczywistego, tzn. jego celem jest utrzymywanie czasu urządzeń pracujących w sieci jak najbliżej czasu UTC, czyli ważne jest by były one synchronizowane względem serwerów, z których najdokładniejszy, czyli stojący na szczycie hierarchii jest źródłem czasu UTC.

PTP W PTP nakłada się szczególny nacisk, aby urządzenia pracujące w sieci były zsynchronizowane jak najlepiej względem siebie. Oczywiście także w przypadku PTP, zazwyczaj stosowane jest podejście synchronizacji urządzeń względem serwera czasu będącego źródłem czasu UTC, lecz nie jest to wymagane.

Protokół RPC Remote Procedure Call

RPC – zdalne wywoływanie procedur RPC to protokół, usługa dzięki której działający na komputerze lokalnym program klienta może wywoływać kod, który jest uruchamiany na serwerze w taki sam sposób jakby był uruchamiany lokalnie RPC dostarcza mechanizmów komunikacji w sieci między programami napisanymi w językach wysokiego poziomu.

RPC- idea

Istotne cechy RPC Obsługa błędów - należy uwzględnić błędy na zdalnym serwerze i błędy sieci Zmienne globalne - serwer nie ma dostępu do zmiennych globalnych klienta Wydajność - wywołanie zdalne jest zazwyczaj o rząd wielkości wolniejsze od lokalnego (tylko wywołanie - wykonanie zależy od wydajności serwera) Autoryzacja - zdalne wywołania mogą przechodzić przez niestrzeżone sieci

Zastosowania Na bazie protokołu RPC opracowano szereg usług sieciowych znajdujących szerokie zastosowanie. Przykładem może być sieciowy system plików NFS a także protokół VXI-11 definiujący szczegóły wymiany komunikatów między serwerami pomiarowymi a aplikacjami klienckimi pozwalającymi na zdalne sterowanie aparatura pomiarową (lab. 107)

Kanały VXI-11 (RPC klient-serwer)

Procedury VXI-11