SKM2 – projekt: specyfikacja wstępna

27.11.2006
Marek Szyprowski
Marcin Goliszewski
SKM2 – projekt: specyfikacja wstępna
Treść zadania
Przy pomocy języka ESTELLE
zaprojektować, zasymulować i porównać
wydajności 2 protokołów: protokołu wykorzystującego technikę przesuwnego
okna i potwierdzenie pozytywne pozycji w oknie oraz protokołu
wykorzystującego technikę przesuwnego okna i potwierdzenie pozytywne
pakietu w oknie. Przyjąć arbitralnie rozmiary okien. Ramki protokołu
wyspecyfikować przy pomocy notacji ASN.1. Na podstawie specyfikacji, za
pomocą odpowiedniego narzędzia, wygenerować kod wczytujący i zapisujący
ww. struktur.
Wstęp
Projektujemy 2 protokoły, które różnią się sposobem potwierdzania. Protokół A
wykorzystuje potwierdzanie pakietu w oknie (potwierdzanie każdego pakietu),
a protokół B – potwierdzanie pozytywne pozycji w oknie (potwierdzenie bajtu
nr x oznacza jednocześnie potwierdzenie wszystkich bajtów o numerach
mniejszych od x). Ponieważ oba protokoły są do siebie bardzo podobne,
tworzymy ich wspólną specyfikację, w której zaznaczone będą różnice
pomiędzy obydwoma protokołami.
Przyjęte typy komunikatów
Przyjęliśmy, że w protokołach występować będą następujące typy
komunikatów:
● CON (id: integer) – nawiązanie połączenia
● CONACK (id: integer) – akceptacja połączenia
● DATA (id: integer, seqnum: integer, data: array of byte) – przesłanie
danych
● ACK (id: integer, seqnum: integer) – potwierdzenie danych
● FIN (id: integer) – zakończeni połączenia
Parametr id pozwala na odróżnienie komunikatów z kilku różnych połączeń
obsługiwanych jednocześnie.
Parametr seqnum oznacza numer sekwencyjny pakietu lub bajtu danych. W
komunikacie DATA oznacza numer nadawanych danych, a w komunikacie ACK potwierdzanych.
Parametr data przenosi dane.
Założenia projektowe
1.
Komunikacja rozpoczyna się od nadania komunikatu CON i komunikatu
zwrotnego – potwierdzenia nawiązania połączenia CONACK z
identyfikatorem połączenia takim samym jak w komunikacie CON.
2. W przypadku zagubienia komunikatu CON po ustalonym czasie
(CONACK TIMEOUT) następuje ponowna próba nawiązania połączenia.
Jeżeli połączenia nie udało się nawiązać po czasie CONACKWAIT
TIMEOUT klient rezygnuje z próby połączenia.
3. W przypadku zagubienia komunikatu CONACK a co za tym idzie nie
otrzymaniu jakiegokolwiek pakietu z danymi od nadawcy po
określonym czasie (CONNECTION TIMEOUT) odbiorca uznaje
połączenie za zerwane.
4. Nadawca kończy połączenie wysyłając komunikat FIN lub nie otrzyma
żadnego potwierdzenia od odbiorcy w określonym czasie (CONNECTION
TIMEOUT). Odbiorca kończy połączenie jeżeli otrzyma komunikat FIN
lub dane nie przyjdą w określonym czasie (CONNECTION TIMEOUT).
5. Komunikacja jest jednostronna – po nawiązaniu połączenia dane są
przesyłane tylko od nadawcy do odbiorcy, a potwierdzenia w stronę
przeciwną.
6. Zaraz po nawiązaniu połączenia (pomyślne przesłanie komunikatów
CON i CONACK) są wysyłane komunikaty z danymi.
7. Każdy kolejny komunikat z danymi jest wysyłany z kolejnym numerem
sekwencyjnym.
8. Stosowana jest technika przesuwnego okna – nadawca nie musi czekać
na potwierdzenie wysłanego komunikatu, może nadać maksymalnie
tyle komunikatów, ile mieści się w oknie.
9. Rozmiar okna jest taki sam dla nadawcy i odbiorcy i ustala się go
arbitralnie na poziomie implementacji. Wyraża on:
● protokół A: ilość pakietów
● protokół B: ilość bajtów
10. Nadawca wysyła wszystkie dane, które są w danej chwili są do
wysłania, jednocześnie:
● protokół A: wysyłany jest ciągły ciąg danych od początku okna aż
do
ostatniego
pakietu
przed
pierwszym
pakietem
niepotwierdzonym znajdującym się w oknie
● protokół B: wysyłane są wszystkie dane z okna
11. Odbiorca potwierdza:
● protokół A: każdy otrzymany komunikat (pakiet).
● protokół B: ostatni otrzymany bajt z ciągłej sekwencji bajtów
otrzymanych w określonym odstępie czasu (ACKDELAY TIMEOUT)
od otrzymania pierwszego bajtu z tej sekwencji lub zapełnieniu
okna.
12. Otrzymanie potwierdzenia oznacza:
● protokół A: poprawne odebranie pakietu o podanym numerze
sekwencyjnym.
● protokół B: poprawne odebranie wszystkich bajtów do bajtu o
zadanym numerze.
13. Gdy nadawca otrzyma potwierdzenie, przesuwa swoje okno o
najdłuższy możliwy ciągły zakres danych z początku okna. W protokole
A dodatkowo oznaczane jako potwierdzone są pakiety nie należące do
tego zakresu, a też potwierdzone. Następnie powstałe w ten sposób
wolne miejsce na końcu okna zapełniane jest nowymi komunikatami,
przy zachowaniu warunku, że w każdej chwili niepotwierdzone dane
mieszczą się w oknie.
14. Niepotwierdzone
będą retransmitowane po upływie pewnego
ustalonego czasu (ACK TIMEOUT). Po jego upływie retransmitowane są
wszystkie niepotwierdzone dane. Dla uproszczenia sterowania
protokołem przyjmujemy, że czas nie jest liczony dla poszczególnych
danych osobno, tylko dla całej grupy danych dany wysłanych z jednego
okna (założenie, że zawartość okna wysłana była w tym samym
momencie).
15. Potwierdzenia, w przypadku zagubienia, nie są retransmitowane – musi
nastąpić retransmisja danej ramki, aby otrzymać ponowne
potwierdzenie.
16. Otrzymanie danych, które zostały już potwierdzona skutkuje nadaniem
ich kolejnego potwierdzenia.
Specyfikacja PDU w postaci struktur ASN.1
DatagramType ::= ENUMERATED {
connect(1),
conack(2),
data(3),
ack(4),
fin(5)
}
Datagram ::= SEQUENCE {
type DatagramType,
connection_id INTEGER,
sequence_number INTEGER,
data OCTET STRING
}
Poszczególne pola oznaczają:
● type – rodzaj ramki, który może przyjąć następujące wartości:
 connect – ramka nawiązująca połączenie,
 conack – ramka potwierdzająca nawiązanie połączenia,
 data – ramka niosąca dane,
 ack – ramka potwierdzająca odebranie danych,
 fin – ramka kończąca połączenie,
● connection_id – numer identyfikacyjny połączenia,
● sequence_number – numer sekwencyjny danych w pakiecie (ramka
DATA) lub numer potwierdzanej ramki (ramka ACK),
● data – przesyłane dane.
Schemat działania protokołu A
Przyjęte oznaczenia:
przejścia między stanami mają postać „warunek / akcja”
bez nawiasów napisane są otrzymane i nadawane komunikaty
w nawiasach <> są warunki i akcje związane z odliczaniem czasu (skrót „T.”
oznacza timeout)
● w nawiasach [] są warunki i akcje związane z danymi i buforami nadawczymi i
odbiorczymi
● sytuacje nie przedstawione na diagramach są ignorowane
●
●
●
Nadawca:
idle
/ CON
<start CONACK T.>
<start CONACKWAIT T.>
<CONACK T.> / CON
conack wait
<CONACKWAIT T.> /
CONACK / <start CONNECTION T.>
<CONNECTION T.> /
/ FIN
connected
/ [w ypełnienie danymi w olnej przestrzeni w oknie]
<ACK T.> or [okno puste]
/ [przesunięcie okna do pierw szego
niepotw iedzonego pakietu]
DATA - [tylko niepotw ierdzone pakiety z okna]
<start ACK T.>
data sent
ACK / <start CONNECTION T.>
[oznaczenie potw ierdzonych pakietów w oknie]
Odbiorca:
idle
CON / CONACK
<start CONNECTION T.>
FIN /
<CONNECTION T.>
connected
DATA / ACK
<start CONNECTION T.>
Schemat działania protokołu B
Nadawca:
idle
/ CON
<start CONACK T.>
<start CONACKWAIT T.>
<CONACK T.> / CON
conack wait
<CONACKWAIT T.> /
CONACK / <start CONNECTION T.>
<CONNECTION T.> /
/ FIN
connected
/ [w ypełnienie danymi w olnego miejsca w oknie]
<ACK T.> or ACK
/ <start CONNECTION T.>
[przesunięcie okna za ostatni
potw ierdzony bajt]
DATA
<start ACK T.>
data sent
Odbiorca:
idle
CON / CONACK
<start CONNECTION T.>
FIN /
<CONNECTION T.>
connected
DATA / <start ACKDELAY T.>
<start CONNECTION T.>
[umieszczenie otrzymanych danych w buforze]
<ACKDELAT T.> or [bufor pełny ]
/ [w yznaczenie ostatniego bajta
z odebranej ciągłej sekw encji danych]
ACK
collecting data
DATA / [umieszczenie otrzymanych danych w buforze]