Formalne modele protokołów i usług

Transkrypt

1 Formalne modele protokołów i usług Model procesu komunikacyjnego: rozszerzony automat skończony Najczęściej przyjmowanym formalnym modelem procesu komunikacyjnego jest model rozszerzonego automatu skończonego. Proces komunikacyjny opisuje się jako złożenie przejść między stanami procesu, ktore można opisać dwoma funkcjami: gdzie: s( n+ ) = f ( s( n), x( n)) y( n) = g( s( n), x( n)) s(n) - stan procesu po n-tym zdarzeniu - funkcja - funkcja przejscia wyjscia x(n) - n-te zdarzenie (sygnał wejściowy, pobudzenie) y(n) - reakcja na n-te zdarzenie (sygnały wyjściowe). Rys 1 ilustruje funkcję przejścia procesu. Nowy stan procesu po zajściu zdarzenia zależy tylko i wyłącznie od rodzaju zdarzenia x i stanu procesu w chwili zajścia tego zdarzenia.. x (n) q s (n+1) j s (n) i x (n) p s (n+1) k t Zablokowanie zdarzeń n+1-sze zdarzenie Rys 3.1 Ilustracja funkcji przejścia procesu Procesy komunkacyjne mają strukturę, którą można modelować przy użyciu automatu skończonego. Stany automatu są związane z oczekiwaniem na zdarzenia (komunikaty) wytwarzane przez współpracujące procesy lub otoczenie systemu. Reakcje automatu są również komunikatami. Graf przejść dla procesu inicjującego połączenie w przykładzie podanym w poprzednim rozdziale przedstawia rysunek. Rysunek 3 przedstawia graf przejść między stanami dla procesu odbierającego z tego samego przykładu.

2 I O N P Rys. 3.2 Graf przejść procesu inicjującego połączenie z przykładu I O N Rys. 3.3 Graf przejść procesu odbierającego z przykładu Inżynieria oprogramowania komunikacyjnego 2

3 SDL SDL (Specification and Description Language) jest najstarszą metoda formalnej specyfikacji protokołów. Opracowano ja pod koniec lat sześćdziesiątych do opisu protokołów połączeń telefonicznych. Metoda ta jest objęta Zaleceniem CCITT od roku Jej obecna wersja [CCITT 92] jest wynikiem stałych prac grupy XI CCITT. Najczęściej stosowana jest wersja SDL z roku Ze względu na to, że SDL był opracowany do opisu protokołów połączeń telefonicznych, miał być zrozumiały przede wszystkim dla użytkowników systemow telefonicznych. Spowodowało to istnienie dwóch równorzędnych reprezentacji specyfikacji wykonanej w SDL [Rockst 82]: graficznej, tekstowej. U podstaw wszystkich tych reprezentacji leży oczywiście ten sam model formalny systemu. W dalszej części będziemy omawiali obie reprezentacje języka jednocześnie. Elementy języka Zasadniczym elementem języka jest proces. Procesy sa środkami reprezentacji dynamicznego zachowania się systemu. Zakłada się, że procesy wykonywane sa współbieżnie. Procesy oczekują w dyskretnych stanach na sygnały ze swego otoczenia. Proces działa tylko w odpowiedzi na zewnatrzne dyskretne pobudzenia i wynikiem jego działalności jest wysłanie dyskretnej odpowiedzi do otoczenia. Po odebraniu sygnału pobudzenia proces dokonuje zmiany stanu (tranzycji). Podczas zmiany stanu proces realizuje akcje w trakcie, w których przetwarza odebraną i lokalną informację oraz wysyła sygnały (odpowiedzi) do innych procesow i do otoczenia systemu. Odpowiedź ta jest odbierana przez określone procesy jako pobudzenie. proces (STATE) sygnał pobudzenia (INPUT) sygnał reakcji (OUTPUT) sygnał upływu czasu (TIMER) Podstawowymi elementami opisu zachownia się procesu na tym poziomie są: stany, sygnały wejściowe i sygnały wyjściowe. Bieżący stanu procesu: Reprezentacja graficzna: Reprezentacja tekstowa: Nazwa_stanu STATE Nazwa_stanu; Inżynieria oprogramowania komunikacyjnego 3

4 Następny stan procesu: NEXTSTATE Nazwa_stanu; Nazwa_stanu Sygnał wejściowy (pobudzenie): Reprezentacja graficzna: Reprezentacja tekstowa: Sygnał wejściowy INPUT Syganł_wejściowy; Sygnał wyjściowy (reakcja): Reprezentacja graficzna: Reprezentacja tekstowa Sygnał wyjściowy OUTPUT Sygnał_wyjściowy; Komentarz: Reprezentacja graficzna: Reprezentacja tekstowa Komentarz /* Komentarz */ Inżynieria oprogramowania komunikacyjnego 4

5 Przykład: Reprezentacja graficzna: Reprezentacja tekstowa Nazwa stanu Sygnał wejściowy Sygnał wyjściowy Komentarz Komentarz STATE Nazwa_stanu; INPUT Syganł_wejściowy; /* Komentarz */ OUTPUT Sygnał_wyjściowy; /* Komentarz */ NEXTSTATE Nazwa_stanu; Nazwa stanu Zamiast nazwy stanu może wystąpić symbo, o specjalnym znaczeniu. Definicja języka przewiduje wystąpenie dwóch takich symboli: gwiazdki (*) i myślnika (-). Pierwszy z nich oznacza dowolny stan procesu, a drugi stan poprzedni procesu. Symbol gwiazdki znajduje zastosowanie we wszystkich takich sytuacjach, w których reakcja procesu na pewne pobudzenie jest identyczna niezależnie od stanu, w którym ten proces się znajduje. Przykładem takiego działania może być rozłączenie połączenia, po którym następuje powrót procesu do stanu początkowego. Konwencja gwiazdkowa (akcja dla każdego stanu procesu): Reprezentacja graficzna: Reprezentacja tekstowa * STATE *; Inżynieria oprogramowania komunikacyjnego 5

6 Przykład: Reprezentacja graficzna: Reprezentacja tekstowa * Rozłącz STATE *; INPUT Rozłącz; OUTPUT Potwierdzenie; NEXTSTATE Przerwany; Potwierdzenie Przerwany Cechą charakterystyczną grafu poprawnie działającego procesu jest istnienie cykli zawierających stan początkowy procesu. Cecha ta jest związana z wymaganiem by z każdego stanu procesu komunikacyjnego istniała droga powrotu do stanu, od którego proces rozpoczął swoje działanie. Brak takiej drogi oznaczałby możliwość wejścia w stan, z którego nie było by wyjścia. Przykład takiego grafu przedstawia rys. 3.. Konwencja gwiazdkowa czasami pozwala na zrealizowanie tego wymagania. S 0 S 1 S 2 S 3 S 5 S 4 Rys. 3.4 Graf procesu z cyklami zawierającymi stan początkowy Użycie myślnika jest równoważne pozostaniu procesu w stanie, w którym się znajduje. Konwencja kreskowa (powrót do stanu początkującego akcję): Reprezentacja graficzna: Reprezentacja tekstowa NEXTSTATE -; - Inżynieria oprogramowania komunikacyjnego 6

7 Przykład: Tekst Znak STATE Tekst; INPUT Znak; OUTPUT Echo_znaku; NEXTSTATE -; Echo_znaku - Zastosowanie konwencji ilustruje rysunek 3.. S 1 S 2 S 3 Rys 3. Pozostanie w stanie s1 Szczególną rolę w opisie zachowania procesów komunikacji zajmuje stan początkowy procesu i dlatego w definicji języka SDL zaproponowano oddzielny symbol do jego oznaczenia. Rozpoczęcie opisu procesu: Reprezentacja graficzna: Reprezentacja tekstowa START START Nazwa_stanu; Przy specyfikowaniu procesów fragmenty specyfikacji umieszczone na różnych stronach łączy się łącznikami. Łączniki pomiędzy stronami specyfikacji: Inżynieria oprogramowania komunikacyjnego 7

8 Zakończenie o etykiecie A na stronie 1 i kontynuacja od etykiety A na stronie 2 Reprezentacja graficzna: Reprezentacja tekstowa A1 A1 JOIN A1;... A1:... Zmienne: Predefiniowane typy zmiennych INTEGER NATURAL - typ liczb całkowitych - typ liczb naturalnych BOOLEAN CHARACTER REAL PID DURATION TIMER TIME CHARSTRING ARRAY POWERSET - typ wartości logicznych - typ znaku - typ liczb rzeczywistych - typ identyfikatora procesu - typ przedziału czasu - typ zegara - typ chwili czasu - typ łańcucha znakowego - typ macierzowy - zbiór podzbiorów Deklaracje zmiennych i typów danych oraz różne teksty, które nie są komentarzami Reprezentacja graficzna: Reprezentacja tekstowa DCL Wartosc INTEGER; Tekst CHARSTRING; DCL Wartosc INTEGER; Tekst CHARSTRING; Inżynieria oprogramowania komunikacyjnego 8

9 Zadanie: Reprezentacja graficzna: Reprezentacja tekstowa Wartosc := 1... Wartosc := Wartosc + 1 Wartosc:=1;... Wartosc:=Wartosc+1; Decyzja: Reprezentacja graficzna: Reprezentacja tekstowa Warunek Warianty odpowiedzi DECISION Warunek (Wariant_1): Zadanie_1; (Wariant_2): Zadanie_2; (Wariant_3): Zadanie_3; ENDDECISION; Warunek Warianty odpowiedzi DECISION Warunek (Wariant_1): Zadanie_1; (Wariant_2): Zadanie_2; (Wariant_3): Zadanie_3; (Wariant_4): Zadanie_4; (Wariant_5): Zadanie_5; ENDDECISION; Przykłady: <0 >0 Wartosc? Włączony? Nie =0 Tak Inżynieria oprogramowania komunikacyjnego 9

10 Reprezentacja graficzna: Reprezentacja tekstowa Liczba odebranych znaków DECISION "Liczba odebranych znaków" (1):..; (2:5):...; >7 (6):...; (7):...; ELSE:...; ENDDECISION; Pomiar czasu: Wszystkie procesy w systemie i jego otoczniu mają dostęp do zegarów (zmiennych typu TIMER) odmierzających czas bezwzględny. Wartości czasu można przetwarzać w zmiennych typu TIME. TIMER SET RESET NOW - typ zegara - procedura ustawienia zegara - procedura zatrzymania i wyzerowania zegara - zmienna typu TIME o wartości odpowiadającej chwili bieżącej Reprezentacja graficzna: DCL T TIMER; ODSTEP TIME; SET (NOW+ODSTEP,T) Reprezentacja tekstowa DCL T TIMER; Odstep TIME;... Potwierdzenie SET(NOW+Odstep,T); NEXTSTATE Potwierdzenie; Timeout STATE Potwierdzenie; INPUT Potwierdzenie; Potwierdzenie T INPUT T; /*Timeout */ RESET T Inżynieria oprogramowania komunikacyjnego 10

11 Przykład PROCESS Inicjator; DCL Licznik INTEGER; Dane TypISDU; Num, Numer INTEGER; T TIMER; SYNONIM P DURATION = 5; START Przerwany; STATE Przerwany; INPUT (ICONreq); Licznik:=1; SET (NOW+P,T); OUTPUT (CR); NEXTSTATE Oczekiwanie; INPUT DR; OUTPUT (IDISind); NEXTSTATE -; INPUT (CC); RESET (T); Numer:=1; OUTPUT (ICONconf); NEXTSTATE Połączony; INPUT (T); DECISION Licznik<4 (TRUE): Licznik:=Licznik+1; SET (NOW+P,T); OUTPUT (CR); NEXTSTATE -; (FALSE): OUTPUT (IDISind); NEXTSTATE Przerwany; ENDDECISION; INPUT (DR); RESET (T); OUTPUT (IDISind); NEXTSTATE Przerwany; STATE Oczekiwanie; Inżynieria oprogramowania komunikacyjnego 11

12 Procesy: Procesy moga być dynamicznie kreowane i niszczone zarówno w czasie inicjacji systemu jak i w czasie jego życia. Proces nie może być zniszczony przez inny proces, lecz może sam się unicestwić. Utworzenie procesu:... Nazwa (Lista parametrów aktualnych) CREATE Nazwa (Lista parametrów aktualnych);... Cztery zmienne predefiniowane: OFF SPRING - PID ostatniego potomka SELF - własny PID PARENT - PID rodzica SENDER - PID nadawcy ostatnio odbranego komunikatu Gdy w środowisku realizującym protokół lub usługę komunikacyjną będą występowały procesy dynamiczne (powoływane do życia) wówczas Zakończenie procesu: Reprezentacja graficzna: Reprezentacja tekstowa STOP; Instancja procesu: PROCESS Nazwa (n1,n2) FPAR... Nazwa (n1, n2) ENDPROCESS Nazwa n 1 - liczba instancji procesu aktywna w miejscu użycia symbolu; n 2 - maksymalna liczba instancji tego procesu w całej specyfikacji. Wartości domyślne obu parametrów: n 1 = 1, n 2 = oo Iok_3wg 3-12

13 Komunikacja między procesami: Droga sygnałowa DS Nazwa (n1, n2) Nazwa (n1, n2) Droga sygnałowa i sygnały: SIGNAL Sygnal1, Sygnal2; komunikacja między procesami DS[Sygnal1, Sygnal2] Nazwa (n1, n2) Nazwa (n1, n2) Adresowanie sygnałów Bezpośrednie: A To Cel Przykład: A TO SENDER; A TO OFFSPRING; A TO P1; Pośrednie (pośrednik w postaci drogi sygnałowej): A VIA DS Iok_3wg 3-13

14 Przekazywanie wartości przez sygnał Sygnały przekazuja dane o strukturze określonej ich typem. Dane te moga być tworzone w oparciu o zmienne lokalne procesu oraz do tych zmiennych zapisywane. DCL V1 NrRamki; V2 Boolean; SIGNAL A(NrRamki, Boolean); A(V1,V2); A(S1,S3); DCL S1 NrRamki; S3 Boolean; SIGNAL A(NrRamki, Boolean); A(5,V2); A(S1); A(,TRUE); A(,S3); A(5,FALSE); A(S1,S3); Semantyka komunikacji procesów Na odbior w procesie może oczekiwać kilka sygnałów. Oczekują one na obsługę w kolejce portu wejściowego. Kolejka ta jest zasadniczo kolejka typu "Pierwszy Zgłoszony Pierwszy Obsłużony", lecz proces ma możliwość "przechowywania" sygnałów i w ten sposob wpływania na kolejność ich obsługi. P1 Sygnal2 Sygnal1 P3 P2 Iok_3wg 3-14

15 A... D B A D B D B D Sygnał D pozosytanie w kolejce i będzie oczekiwał na skonsumowanie w dalszych stanach. Na odbior w procesie może oczekiwać kilka sygnałów. Oczekują one na obsługę w kolejce portu wejściowego. Kolejka ta jest zasadniczo kolejka typu "Pierwszy Zgłoszony Pierwszy Obsłużony", lecz proces ma możliwość "przechowywania" sygnałów i w ten sposob wpływania na kolejność ich obsługi. Sygnały przekazuja dane o strukturze określonej ich typem. Dane te moga być tworzone w oparciu o zmienne lokalne procesu oraz do tych zmiennych zapisywane. Iok_3wg 3-15

16 Procedura: Definicja PROCEDURE Nazwa FPAR Lista parametrów formalnych Nazwa procedury... Przywołanie procedury: Nazwa (lista param. aktualnych) Makrodefinicja: Definicja MACRODEFINITION Nazwa FPAR Lista parametrów aktualnych a b A>0 R:=0 Yes c d Iok_3wg 3-16

17 Przywołanie: a b Nazwa (lista param. aktualnych) c d Iok_3wg 3-17

18 Zasady strukturalizacji Definicje modelu określaja typy elementow metody specyfikacji. Definiując dalej pojęcia metody będzie mowa o typie elementu. Elementy dowolnego typu mają swoje instancje. Instancja ma wszystkie cechy przypisane typowi elementu i jest konkretną realizacją elementu. Może istnieć dowolnie wiele instancji pewnego elementu będacych instancjami tego samego typu. Statyczna struktura systemu jest modelowana jako zbiór bloków komunikujących się za pomocą kanałów. Kanały łączą bloki wzajemnie i łączą bloki z granicami systemu (z otoczeniem systemu). Granice systemu oddzielają system od jego otoczenia. Zakłada się przy tym, że otoczenie systemu zachowuje się w sposób podobny jak modelowany system. Kanały działają jako jednokierunkowe środki transportu sygnałów przesyłanych między blokami. Struktura specyfikowanego systemu wynika z podziału systemu na bloki, kanały i procesy. Strukturalizacja może być głębsza i dopuszczalne jest wydzielanie podblokow, podkanałów i podprocesów. Strukturalizacja kanału polega na wydzieleniu nowych blokow i nowych kanałów pomiędzy tymi blokami. Strukturalizacja polega na podziale protokołu/usługi na bloki, w ktorych działają procesy. Kolejnym narzadziem strukturalizacji procesu sa procedury. Procedura jest rozumiana tak jak w językach programowania z tym, że może ona zawierać akcje i zmiany stanu. Procedury mogą tworzyć bibliotekę i być wykorzystywane przez różnych reprezentantów procesu, bądź przez reprezentantow innych procesow. Przy sporządzaniu specyfikacji przydatnym środkiem jej uproszczenia jest makro. Makro reprezentuje pewien fragment specyfikacji, ktory jest dołączany do specyfikacji za pomocą jego nazwy. Makro tym różni się od procedury, że procedura jest przywoływana, a makro jest dołączane do specyfikacji. Makro jest środkiem upraszczajacym edycję specyfikacji. Ostatnim środkiem ułatwiającym strukturalizację specyfikacji jest opcja. Środek ten umożliwia specyfikowanie rozwiązań alternatywnych. W przypadku, gdy przedmiot specyfikacji ma być zrealizowany, wybierana jest jedna z kilku dopuszczalnych opcji. Iok_3wg 3-18

19 SDL, a języki implementacji Istnieja ścisłe powiazania pomiędzy SDL, a językiem programowania systemów telekomunikacyjnych CHILL. Przykładowo wspólne są koncepcje procesu i sygnału. int Receive(int Adres, int OdbDane1, int OdbDane2); void Send(int Adres, int Dane1, int Dane2); void Reset(); void Set(); int State; #define NextState State #define Przerwany 1 #define Oczekiwanie 2 #define Polaczone 3 #define Nadane 4 #define User 10 #define ICONreq 11 #define IDISreq 12 #define IDISind 13 #define ICONconf 14 #define IDATreq 15 #define Medium 100 #define CR 101 #define DR 102 #define CC 103 #define DT 104 #define AK 105 #define Timer1 300 #define Timeout1 5 int Licznik; int Numer; int Dane; main () { switch (State) { case Przerwany: switch (Receive(Num, Dane)) { case ICONreq: Licznik=1; Send(Medium,CR); Set(Timer1,Timeout1); NextState=Oczekiwanie; Iok_3wg 3-19

20 break; case DR: Send(User,IDISind); NextState=Przerwany; break; }; case Oczekiwanie: switch (Receive(Num, Dane)) { case CC: Send(User,ICONconf); Reset(Timer1); Numer=1; NextState=Polaczone; break; case Timer1: if (Licznik<4) { Send(Medium,CR); Licznik++; Set(Timer1,Timeout1); } else { Send(User,IDISind); NextState=Przerwany; }; break; case DR: Reset(Timer1); Send(User,IDISind); NextState=Przerwany; break; }; break; case Polaczone: switch (Receive(Num,Dane)) { case IDATreq: Send(Medium,DT,Numer,Dane); Licznik=1; Set(Timer1,Timeout1); NextState=Nadane; break; case DR: Reset(Timer1); Send(User,IDISind); NextState=Przerwany; break; }; Iok_3wg 3-20

21 } } break; case Nadane: switch (Receive(Num, Dane)) { case AK: Reset(Timer1); if (Num==Numer) { succ(numer); NextState=Polaczone; } else { if (Licznik<4) { Send(Medium,DT,Numer,Dane); Licznik++; Set(Timer1,Timeout1); NextState=Nadane; } else { Send(User,IDISind); NextState=Przerwany; } } break; case DR: Reset(Timer1); Send(User,IDISind); NextState=Przerwany; break; }; break; Iok_3wg 3-21

22 Notacja ASN.1 Typ i wartość obiektu - ASN.1 (ISO 8824, CCITT X.208). Komunikacja między dowolnymi komunikującymi się elementami systemu rozproszonego wymaga nie tylko precyzyjnego zdefiniowania agorytmu ich przetwarzania, ale również formatu wymienianych danych. Złożoność danych transmitowanych przez rozproszone aplikacje wymaga do ich określenia tzw. Języka Reprezentacji Zewnętrznych Danych (External Data Representation Language XDR). Rozproszone aplikacje mogą działać w różnych środowiskach. Można rozważać cztery rodzaje różnic między nimi: różne typy komputerów, np.: przesłanie danych między komputerem pracującym ze słowem 16 bitowym i komputerem pracującym ze słowem 64 bitowym. różne języki programowania aplikacji, np. konieczność przesłania wartości zmiennych z programu napisanego w C do programu napisanego w FoxPro. różne formaty danych łączonych aplikacji, np.: programy poczty elektronicznej mające różny format przesyłanych danych. różne typy sieci i obsługujących je urządzeń. np. NUMERIC DATE System A ASN.1 System B np. int? Baza danych Baza danych np. FoxPro np. C *.dbf *.baz BER Warstwa prezentacji Konieczność opracowania XDR dla systemów komunikacyjnych została zauważona już przed powstaniem standardu. Jednak wcześniejsze aplikacje ograniczały się do tylko jednego języka programowania np.: XDR firmy SUN, lub miały tylko jedną postać transmitowanych danych Xerox Courier[6]. Iok_3wg 3-22

23 ASN.1 (Abstract Syntax Notation 1) stworzona przez ISO oraz CCITT i przedstawiona w Zaleceniu X.208 to język specyfikacji typów danych przesyłanych między aplikacjami. ASN.1 nie jest zależne od żadnego innego języka programowania. Zaletą takiego podejścia jest możliwość ominięcia ograniczeń opisanych powyżej. Jednak z drugiej strony, ze względu na ogólność typów danych ASN.1, utrudnione lub często niemożliwe jest bezpośrednie odwzorowanie typów danych opisanych przy pomocy ASN.1 na typy innego języka programowania. Wyizolowane i niezależne od przesyłanych obiektów informacyjnych zasady kodowania i dekodowania typów definiowanych przy pomocy tej notacji zezwalają na tworzenie nowych definicji postaci transmitowanych danych. Standardowe rozwiązanie BER (Basic Encoding Rules) zawarty w Zaleceniu X.209, może być zastąpione innym z punktu widzenia aplikacji korzystniejszym sposobem kodowania danych. Zasady te mogą być dowolne, jednak standard zawiera już propozycję w postaci BER. W siedmiowarstwowym modelu ISO ASN.1 występuje w górnych warstwach. Jest umieszczona w warstwie aplikacji, podczas gdy reguły kodowania BER są związane są z warstwą prezentacji. Potencjalnie ASN.1 może służyć do opisu protokołów dowolnej z warstw modelu, jednak jej podstawowym zadaniem jest określenie formatów danych protokołów występujących w warstwie aplikacji. Dane przesyłane między aplikacjami są bardzo zróżnicowane i nie można jednoznacznie określić ich wszystkich rodzajów używanych w aplikacjach działających w różnych środowiskach. Nie ma możliwości zdefiniowania zbioru wszystkich możliwych informacji przesyłanych między aplikacjami już w przypadku bardzo prostych danych. Bez odpowiedniego podziału danych jakakolwiek interpretacja jest niemożliwa. W celu wymiany i interpretacji danych przesyłanych na wysokim poziomie pomiędzy rozproszonymi aplikacjami potrzebny jest jednakowy format ich przedstawienia dla wszystkich aplikacji, lub wymaganie od każdej aplikacji znajomości wewnętrznego formatu danych wszystkich innych aplikacji. To drugie podejście w sposób oczywisty jest niemożliwe do implementacji, a dodatkowo niezgodne z ideami OSI. Istnieje możliwość narzucenia jednolitego języka do porozumiewania się w warstwie aplikacji. Wówczas wszystkie dane przesyłane między aplikacjami miałyby identyczne znaczenie dla wszystkich użytkowników. Takie podejście jest również niezgodne z ideami OSI zakładającymi przezroczystość warstw. Dlatego wybrane rozwiązanie zakłada wybór jednolitego formatu danych transmitowanych w warstwie prezentacji. Odpowiednie tłumaczenie przesłanych danych na podstawie wspólnego dla obu aplikacji opisu w ASN.1 przebiega w warstwie aplikacji. Notacja używana do definiowania typów zmiennych w ASN.1 jest bardzo zbliżona do sposobu zapisu używanego w większości języków programowania. Ze względu na Iok_3wg 3-23

24 to, że jest to sposób zapisu typów danych, brak jest słów kluczowych związanych z wykonywaniem instrukcji takich jak pętle czy instrukcje warunkowe. Język zawiera kilka wbudowanych typów danych i zespół zasad, które pozwalają tworzyć samodzielnie nowe, bardziej skomplikowane typy danych oraz przyznawać stałe wartości niektórym elementom wchodzącym w skład tak zdefiniowanych typów danych. Ogólna formuła tworzenia nowych typów danych polega na przypisaniu pewnego wcześniej zdefiniowanego typu do jego nowego identyfikatora. Przykład: NowyIdentyfikator ::= InnyTyp lub, WeatherReport ::= SEQUENCE { stationno INTEGER, timeofreport INTEGER, dateofreport INTEGER, temperature INTEGER, winddir INTEGER, humidity INTEGER, } W ten sposób użycie nowej nazwy w definicji wartości (lub typu) powoduje przypisanie tej wartości typu odpowiadającego wcześniejszej definicji. Wartości InnyTyp z przykładu może odpowiadać dowolny prosty typ ASN.1 lub jeden z typów złożonych utworzonych z typów prostych lub wcześniej zdefiniowanych. ASN.1 umożliwia również przedstawienie pewnych obiektów informacyjnych o określonym z góry typie i nadanej im odgórnie wartości. W tym celu wykorzystuje się tzw. value notation. Wartości zdefiniowane przy jej użyciu mają głównie zastosowanie w celach przykładowych, aby lepiej zaprezentować nowo tworzone typy danych. Przykład: wartość IdentyfikatorTypuWartości ::= wartośćzgodnazidtypuwart lub, weatherreportmonday WeatherReport ::= { stationno 200, timeofreport 1504, dateofreport , temperature 30, winddir 150, Iok_3wg 3-24

25 humidity 80 } Wbudowane typy danych języka ASN.1 obejmują następujące typy: INTEGER, BOOLEAN, REAL, BIT STRING, OCTET STRING, ENUMERATED, NULL, OBJECT IDENTIFIER. Typ INTEGER odpowiada wszystkim wartościom dodatnich i ujemnych liczb całkowitych. Brak ograniczenia zakresu dla liczb typu INTEGER spowodowany jest tym, że ASN.1 nie interesuje się sposobem reprezentacji tych danych na komputerze oddając tę pracę zasadom kodowania. Przykład definicji typu pochodnego od typu INTEGER: ImageLoadMode ::= INTEGER { other(1), -- Unknown LocalBoot(2), -- Load image from local NetBoot(3) -- Load image from remote } USmallInt ::= INTEGER (0..255) Przykład definicji wartości dla tego typu: agentimageloadmode ImageLoadMode ::= other Wbrew pozorom symbole "other" i "NetBoot" nie ograniczają zakresu typu ImageLoadMode do przedziału od 1 do 3, ale wyłącznie nadają tym dwu liczbom nowe symboliczne nazwy. Typ BOOLEAN zawiera dwie wartości, odpowiadające logicznym wartościom TRUE i FALSE. Przykład definicji typu pochodnego od typu BOOLEAN SwitchStatus ::= BOOLEAN Przykład definicji wartości dla tego typu: switch SwitchStatus ::= TRUE Iok_3wg 3-25

26 Typ REAL to podobnie jak INTEGER zbiór wszystkich wartości liczb rzeczywistych. Jak w przypadku INTEGER ASN.1 nie ogranicza zakresu tych liczb gdyż tym zajmuje się reguła dekodowania wartości. Przykład definicji typu pochodnego od typu REAL: Float ::= REAL Przykład definicji wartości dla tego typu: e REAL ::= {27182, 10, -4} Z oczywistych względów nie można przypisać wartościom tego typu odrębnych nazw jak w przypadku typu INTEGER. Typ BIT STRING zawiera ciąg bitów o dowolnej długości. Nie musi być to wielokrotność 8. Przykład definicji typu pochodnego od typu BIT STRING: FacsimileInformation ::= BIT STRING SunnyDaysOfMonth ::= BIT STRING { first(1), third(3), } Przykład definicji wartości dla tego typu: sunday SunnyDaysOfMonth ::= '810204'H Typ ANY nie jest właściwie osobnym typem, ale rezerwacją miejsca na daną dowolnego typu i dowolnego rozmiaru. Dana i jej typ, który podstawiony zostanie w miejsce ANY wybierany jest w czasie działania aplikacji. Przykład definicji typu pochodnego od typu ANY: Contentindication ::= INTEGER MessageContent ::= ANY DEFINED BY ContentIndication Typ NULL stosowany jest jedynie wyjątkowo zazwyczaj w konstrukcjach typu CHOICE. Jego stosowanie jest obecnie odradzane ze względu na bardziej efektywne formy zapisu. Przykład definicji typu pochodnego od typu NULL: MiddleName ::= CHOICE { is OCTET STRING, isnot NULL} Przykład definicji wartości dla tego typu: Iok_3wg 3-26

27 midname MiddleName ::= isnot Typ OCTET STRING to dowolnej długości ciąg znaków. Znaki mogą przybierać dowolną wartość od 0 do 255. Każdy znak zajmuje osiem bitów. Ciąg ten nie musi być zakończony znakiem 0 jak w przypadku C, a za określenie jego długości odpowiedzialne są wyłącznie zasady kodowania. Typ OCTET STRING jest w samej definicji notacji okrojony przez co powstaje kilka nowych typów zawierających charakterystyczne zestawy znaków, np. typy NumericString, PrintableString i inne. Przykład definicji typu pochodnego od typu OCTET STRING: AtLeastOneByte ::= OCTET STRING (SIZE (1..MAX)) Przykład definicji wartości dla tego typu: anyone AtLeastOneByte ::= '4fde'h Typ ENUMERATED to skończony zbiór wartości, którego każdy element ma odpowiadającą mu wartość liczbową, służącą jako dodatkowy identyfikator. W przeciwieństwie do typu INTEGER przyznanie wartości określonego symbolu powoduje umieszczenie tej wartości w typie ENUMERATED. Wartości nie umieszczone w definicji typu nie wchodzą w jego skład. Brak jest relacji porządkującej wartości tego typu. Wartość numeryczna liczb odpowiadających identyfikatorom nie jest istotna, wykorzystywana jest tylko przy kodowaniu. Przykład definicji typu pochodnego od typu ENUMERATED: Priority ::= ENUMERATED { low(-1), Przykład definicji wartości dla tego typu: medium(0), high(1) } status Priority ::= low Typ OBJECT IDENTIFIER jest wbudowanym w język typem ściśle związanym z prezentacją i identyfikacją obiektów znajdujących się w Drzewie Identyfikatorów Obiektów (OIT) tworzonym i nadzorowanym przez ISO. Głównym zadaniem drzewa OIT jest zapewnienie bezbłędnego dostępu do obiektów informacyjnych definiowanych w ogólnie dostępnych aplikacjach np.: protokołach sieciowych. Węzły tego drzewa oznaczone są numerycznie przez ciąg nieujemnych liczb całkowitych, a identyfikator danego węzła to ścieżka jaką trzeba pokonać od korzenia tego drzewa do interesującego nas węzła. Tworzenie nowych węzłów drzewa jest ściśle Iok_3wg 3-27

28 nadzorowane przez ISO. Ten typ danych używany jest przy tworzeniu nowych aplikacji. Przykład definicji typu pochodnego od typu OBJECT IDENTIFIER: CCProduct ::= OBJECT IDENTIFIER Przykład definicji wartości dla tego typu: joint-iso-ccitt OBJECT IDENTIFIER ::= {2} directory OBJECT IDENTIFIER ::= {joint-iso-ccitt ds(5)} Jak widać tworzenie nowych typów danych w ASN.1 nie nastręcza większych trudności. W tym celu możemy okroić istniejący dotychczas typ danych poprzez ograniczenie zakresu (p. INTEGER) lub ograniczenie rozmiaru( p. OCTET STRING). Definicja typów złożonych Oprócz redefinicji typów prostych możemy tworzyć bardziej skomplikowane typy jako kombinację typów podstawowych lub wcześniej zdefiniowanych. Język zapewnia nam w tym celu następujące konstrukcje do tworzenia typów złożonych: SEQUENCE SET SEQUENCE OF SET OF CHOICE Typy utworzone przy użyciu SEQUENCE i SET są do siebie zbliżone i przypominają konstrukcję struct w C lub record w PASCALu. Różnica między tymi dwoma typami uwidacznia się w procesie kodowania i przesyłania danych. Typ utworzony przy pomocy SEQUENCE wymaga aby dane były przesyłane w takiej kolejności w jakiej zostały zapisane w definicji typu. W przypadku SET kolejność przesyłanych danych jest dowolna a odbiornik orientuje się w typie danej na podstawie znacznika (tag) jaki z nią przyszedł. Różnice te są w praktyce nie widoczne na poziomie ASN.1. Przykład definicji typu złożonego: RejectTPDU ::= SET { credit Credit, Message ::= SEQUENCE { destref Reference } envelope MessageTransferEnvelope, content Content } Iok_3wg 3-28

29 Przykład definicji wartości dla typu złożonego: val RejectTPDU ::= { destref 90, credit 9000} msg Message ::= { envelope '0d4f'h, content "content of envelope"} Jeżeli dana przesyłana może przyjąć jeden z kilku typów to reprezentacja typu tej danej tworzona jest przy pomocy typu CHOICE. Konstrukcja ta przypomina konstrukcję union z języka C. Spośród kilku typów danych, które wchodzą w skład CHOICE przesłany zostaje tylko jeden i odpowiadający mu znacznik. Przykład definicji typu CHOICE: TypN ::= CHOICE { x y REAL, INTEGER, z BIT STRING(SIZE(32)) } Przykład definicji wartości dla typu CHOICE: val1 TypN ::= x {45,10,2} val3 TypN ::= z '0000ffff'h Typ SET OF i SEQUENCE OF to ciąg pewnej liczby obiektów tego samego typu. Jest to typ danych podobny do tablic występujących w innych językach programowania np.: typu array zdefiniowanego w PASCALu. Znacząca różnica to brak ograniczenia rozmiaru typów ASN.1, podczas gdy w PASCALu rozmiar musi być dokładnie określony. W przypadku ASN.1 możliwe jest również określenie rozmiaru poprzez użycie ograniczenia rozmiaru słowem kluczowym SIZE. Typy SET OF i SEQUENCE OF podobnie jak typy SET I SEQUENCE odróżnia od siebie istotność kolejności występowania elementów wewnątrz danej jednego z tych typów. Kolejność jest istotna w przypadku SEQUENCE OF. Przykład definicji typu: Students ::= SEQUENCE SIZE(100) OF StudentID Parameters ::= SET OF Parameter Przykład definicji wartości dla tego typu: TempInGdańskFeb Readings ::= { 0,3,5,0,-1,3,6,9} Iok_3wg 3-29

30 Najobszerniejszą i zarazem najtrudniejszą w implementacji formę tworzenia nowych typów danych tworzy mechanizm makroinstrukcji zdefiniowany w standardzie ASN.1. Nowe konstrukcje rozszerzające składnie ASN.1 opisywane są definicjami zapisanymi w postaci BNF. Ta forma zapisu pozwala na przedstawienie syntaktyki konstrukcji opisanych w definicji, nie ma jednak możliwości analizy semantyki tych konstrukcji, która zapisana jest w postaci komentarzy towarzyszących makroinstrukcjom. Z tego powodu nie jest możliwe automatyczne rozszerzanie składni ASN.1 poprzez dołączanie do niej dynamicznie wczytywanych makroinstrukcji. Wiele makroinstrukcji mimo, że nie wchodzą w skład standardu ASN.1 upowszechniło się i są powszechnie wykorzystywane np w przypadku konstrukcji MIB-ów. Obsługiwane przez analizator są OBJECT-TYPE i TRAP-TYPE. Ich znaczenie semantyczne opisane jest w punkcie o SNMP(3.0). Tu krótko bądzie omówiona ich składnia. Makro OBJECT-TYPE wymaga wypełnienia następujących pól: SYNTAX - typ zmiennej w danym węźle. Dowolny typ zdefiniowany module. ACCESS - dostęp do tej zmiennej (read-only, read-write...). STATUS - status zmiennej obowiązkowa, dowolna, nieużywana. Dodatkowo mogą występować pola: DESCRIPTION - opis zmiennej. Ciąg znaków w cudzysłowach. REFERENCE - odwołanie do innych opisów zmiennej. Ciąg znaków w cudzysłowach. DEFVAL - wartość zgodna z typem określonym w polu SYNTAX INDEX - pola klucze. Występuje tylko w przypadku gdy typ zmiennej jest typem złożonym. W makro TRAP-TYPE obowiązkowo muszą być wypełnione pola: ENTERPRISE - Węzeł w drzewie MIB. Określa organizację, która jest twórcą urządzeń nadających te ramki. VARIABLES - Opcjonalna lista zmiennych(węzłów w drzewie), które zawarte są w nadchodzącej ramce TRAP. Opcjonalne jest wypełnienie pól: DESCRIPTION - Ciąg znaków zawierający opis danej ramki TRAP REFERENCE - Ciąg znaków zawierający odwołania do danego TRAP w innych obiektach i modułach. Modułowy charakter definicji tworzonych w notacji ASN.1 ASN.1 ma naturę języka modułowego i zezwala na wykorzystywanie w module danych zawartych w innych modułach. Pogrupowanie poszczególnych definicji i nazwanie ich odrębną nazwą daje możliwość lepszej orientacji w definicjach danych. Iok_3wg 3-30