Sieci Komputerowe 2008/2009. Opis Protokołu

Transkrypt

1 Sieci Komputerowe 2008/2009 Opis Protokołu (Iteracja 2/2) Paweł Bedyński pb /12

2 1. Streszczenie Poniższy dokument opisuje specyfikację protokołu do obsługi aukcji internetowych, w którym nie występuje żaden centralny serwer, a wszyscy użytkownicy są równouprawnieni. Składa się z następujących części: opis celów protokołu opis założeń opis formatów komunikatów opis stanów 2. Cele Protokół ma umożliwiać dwie fazy komunikacji przeprowadzane podczas każdej aukcji. faza pierwsza: W pierwszej fazie użytkownicy zadają sobie na wzajem pytania o udostępniane przedmioty. Możliwe jest także zadanie pytania doprecyzowującego o konkretny przedmiot wystawiony przez danego użytkownika. Faza pierwsza nie wymaga identyfikacji użytkowników ani zapewnienia przymusu udzielenia odpowiedzi (lub innych potwierdzeń). faza druga: W drugiej fazie użytkownicy zapisują się do licytacji danego przedmiotu, licytują dany przedmiot (wysyłają oferty nowej ceny), dostają informacje o nowej cenie produktu (jeśli są zapisani do licytacji danego przedmiotu) oraz są informowani o zakończeniu aukcji (wraz z wynikiem aukcji - ostateczną ceną). Faza druga wymaga wzajemnej identyfikacji poprzez mechanizm identyfikatorów. 3. Terminologia Wykaz używanych w tekście terminów i ich znaczenia: Wystawca użytkownik instancji protokołu wystawiający na aukcji określony, wystawiany przedmiot Oferent Identyfikator Potwierdzenie pozytywne Potwierdzenie negatywne użytkownik instancji protokołu zgłaszający ofertę kupna danego przedmiotu unikatowy numer służący do rozpoznawania użytkowników instancji protokołu (dot. fazy drugiej) komunikat wysyłany przez użytkownika instancji protokołu, który odebrał inny komunikat w celu potwierdzenia jego przyjścia. Uwaga: dodatkowo potwierdzenie pozytywne oznacza, że zaistniała sytuacja zgodna z intencją użytkownika, który otrzymuje potwierdzenie pozytywne. (dot. fazy drugiej) podobnie jak potwierdzenie negatywne, z tym że: Uwaga: potwierdzenie negatywne informuje, że zaistniała sytuacja niezgodna z intencją użytkownika oczekującego na potwierdzenie. 2/12

3 4. Założenia 1. Połączenie Zakładamy że adresy IP użytkowników protokołu dostarczane są z zewnątrz tj. zadaniem protokołu nie jest ich pozyskiwanie. Stroną nawiązującą połączenie jest za każdym razem Oferent. Połączenie zamyka również Oferent - zauważmy że posiada on wiedzę o innych powiązaniach z wystawcą, którego połączenie chce zamknąć (inna aukcja w fazie drugiej łącząca więzią wystawca/oferent dwóch użytkowników). Nawiązanie połączenia następuje w chwili gdy użytkownik A chce poznać przedmioty wystawiane przez użytkownika B (inicjuje A w sytuacji gdy nie ma jeszcze połączenia A-B). Zerwanie połączenia następuje po otrzymaniu informacji o zakończeniu aukcji (sprawdzane jest czy jest to ostatnia aukcja łącząca A i B), lub po otrzymaniu negatywnych potwierdzeń na wszystkie żądania przyłączenia się do aukcji (np. na skutek posiadania przez oferenta zbyt starej [nieobsługiwanej już] wersji protokołu). Pozostałe przypadki reguluje rozdział Timeout. 2. Powiązania z innymi protokołami Protokół działa w warstwie aplikacji ISO-OSI. Pierwsza faza komunikacji nie wymaga (w założeniach zadania) niezawodności połączenia, jednak ewentualna funkcjonalność przesyłania plików-opisów wystawianych przedmiotów skłania to wykorzystania protokołu TCP a nie UDP. Druga faza wymaga już niezawodnego połączenia zatem zostanie zrealizowana w oparciu o protokół TCP. 3. Model komunikacyjny Protokół zakłada brak jakiegokolwiek centralnego serwera sterującego aukcjami. Każdy użytkownik instancji protokołu jest zarówno serwerem (tzn. może prowadzić aukcje jako Wystawca) jak i potencjalnym Oferentem. 5. Identyfikacja użytkowników Uwaga: dotyczy fazy II Identyfikacja użytkowników odbywa się poprzez kolejność zgłoszeń na aukcje i jest identyfikacją per przedmiot a nie per osoba. Oferent zgłaszając się na aukcje wysyła do Wystawcy komunikat zgłoszeniowy, a ten wystawia mu identyfikator. Identyfikatorem jest czwórka : numer portu Oferenta numer przedmiotu ustalony przez Wystawce (numer ten Oferent zdobywa w fazie I) numer wystawiany przez Wystawce według kolejności zgłoszeń na dany przedmiot adres oferenta (zmiennej długości ciąg bajtów), może to być adres IP oferenta. Identyfikator jest odsyłany do Oferenta jako potwierdzenie zapisu na aukcje. Od tej pory Oferent i Wystawca autoryzują komunikaty dotyczące danego przedmiotu tym właśnie numerem. Uwaga: to w szczególności oznacza, że ci sami użytkownicy protokołu mogą poprawnie identyfikować się wzajemnie za pomocą wielu różnych identyfikatorów (jeśli dotyczy to różnych przedmiotów). 3/12

4 6. Opis formatów komunikatów Założenia: Każdy komunikat składa się z Header'a i następującego bezpośrednio po nim właściwego komunikatu (typy opisane w dziale typy komunikatów) porządek octetów w liczbach: sieciowy sposób interpretacji liczb ze znakiem: jak w arytmetyce U2 sposób reprezentacji napisów: domyślnie UTF-8 (ew. rozszerzenia mogą dodać inne formaty kodowania znaków, zabezpieczeniem przed odczytaniem napisów w złym kodowaniu może być mechanizm wersji) Typy pomocnicze: Header: MSG_HDR{ msg_id; protocole_v; msg_len; msg_id to numer komunikatu właściwego (zgodnie z sekcją Numery) protocole_v to wersja protokołu, a tym samym komunikatu (nowa wersja choćby jednego komunikatu implikuje nowy numerek protocole_v). UWAGA: msg_len to całkowita długość komunikatu właściwego tzn BEZ headera. Zatem komunikaty tego samego typu mogą mieć różną długość (wersje). Identyfikator: ID_T { product_id; queue_id; port key_len; octet[key_len] key; product_id - unikalny dla Wystawcy identyfikator wystawianego produktu. UWAGA: format key (znaczenie bajtów) może być przypisywane za pomocą mechanizmu wersji. key_len - długość jedynie pola key Plik: FILE_T { uint64 file_len; octet[file_len] file_data; file_name_len; octet[file_name_len] file_name; 4/12

5 file_len - pole zawierające długość jedynie pola file_data (tj. rozmiar pliku w bajtach). file_name_len pole zawierające długość jedynie pola file_name (tj długość nazwy pliku) kodowanie domyślne lub zmienione przez wersje. Cecha przedmiotu: (to pary np.: <kolor,zielony>) OBJECT_FEATURE_T { uint16 key_len; octet[key_len] key; value_len; octet[value_len] value; key_len - pole zawierające długość jedynie pola key value_len pole zawierające długość jedynie pola value Opis przedmiotu: OBJECT_DETAILS_T { unit32 product_id; uint8 total_files; FILE_T[total_files] files_array; uint16 total_features; OBJECT_FEATURE[total_features] features; product_id to numerek przedmiotu unikalny wśród przedmiotów wystawianych przez jednego wystawce (nadawany przez wystawce) total_files pole zawierające liczbę struktur FILE_T dołączonych do struktury OBJECT_DETAILS_T total_features pole zawierające liczbę struktur OBJECT_FEATURE_T dołączonych do struktury OBJECT_DETAILS_T Typy komunikatów: Typy używane w fazie I: REQUEST_ONE_I_MSG_T { product_id; // future_use; Jest to zapytanie przez oferenta o przedmiot któremu wystawca nadał numer product_id. Pole future_use w kolejnych wersjach protokołu może konkretyzować zapytanie oferenta (o pojedyncze szczegóły opisu przedmiotu) REQUEST_I_MSG_T { Jest to pytanie o wszystkie przedmioty danego użytkownika. Wszystko co w obecnej wersji protokołu jest potrzebne do zadania takiego pytania jest zawarte w numerze komunikatu (Header). Wprowadzam tą strukturę dla ew. przyszłych wersji (tu np. użytkownik może wpisać rodzaj filtra które informacje o produktach już teraz chce poznać). 5/12

6 ANSWER_I_MSG_T { total_items; OBJECT_DETAILS_T[total_items] items; total_items pole zawierające liczbę struktur OBJECT_DETAILS_T dołączonych do struktury ANSWER_I_MSG_T, a zatem określa o ilu produktach oferent się dowiaduje. Typy używane w fazie II: ENQUEUE_REQUEST_MSG_T { unit32 item_id; msg_nr; Uwaga: msg_nr - to numer komunikatu (nie jego typ). pole to jest potrzebne byśmy wiedzieli, że ew. potwierdzenie negatywne odnosi się właśnie do tego żądania. są to kolejne liczby naturalne - w zasadzie ważne jest byśmy nie wysyłali dwóch komunikatów o tym samym numerku do tej samej osoby odnośnie tego samego przedmiotu w zbyt krótkich odstępach czasu (a to jest raczej pewne). (ustala Oferent) NEW_OFFER_MSG_T { msg_nr; float64 price; ID_T id; NEGATIVE_CONFIRMATION_MSG_T { errno; msg_nr; ID_T id; errno numer błędu zgodny z sekcją Numerki LEADING_PRICE_MSG_T { msg_nr; uint8 is_finished; float64 price; ID_T id; Uwaga: pole is_finished z wartością niezerową oznacza komunikat o zakończeniu aukcji danego przedmiotu wtedy price oznacza końcową cenę produktu. msg_nr patrz uwaga z ENQUEUE_REQUEST_MSG_T AUCTION_RESULT_REQ_T{ product_id; 6/12

7 7. Opis wymienianych komunikatów Numery komunikatów opisane są w sekcji Numerki 1. REQUEST_ITEMS_LIST_MSG : REQUEST_I_MSG_T Uwaga: powyższe założenia protokołu oznaczają, że Wystawca przedmiotu może zdecydować jaką cześć informacji o poszczególnych wystawianych przez siebie przedmiotach wysyła w odpowiedzi na ten komunikat. (może wysyłać same numerki, a może też pełną informacje o każdym przedmiocie), przyszłe wersje protokołu mogą specyfikować konkretyzacje pytania do wystawcy (np. poprzez filtry). 2. REQUEST_ITEM_DETAIL_MSG(product_id) : REQUEST_ONE_I_MSG_T zapytanie o szczegółowy opis przedmiotu (product_id) wystawianego przez wystawce Uwaga: wersje - analogicznie jak w komunikacie REQUEST_ITEMS_LIST_MSG.. 3. ANSWER_ITEMS_LIST_MSG(products_list) : ANSWER_I_MSG_T odpowiedź wystawcy, w której informuje użytkownika instancji protokołu o wystawianych przez siebie przedmiotach. 4. ANSWER_ITEM_DETAIL_MSG(product_id) :ANSWER_I_MSG_T odpowiedź wystawcy, w której informuje użytkownika instancji protokołu o szczegółach dotyczących przedmiotu, o który user pytał. Uwaga: w praktyce rozróżnianie odpowiedzi o konkretny przedmiot i listę przedmiotów jest zbędne (to jest kwestia czy tablica jest jedno czy wieloelementowa)... Taki jednak był wymóg zadania więc wprowadzam ten komunikat. 5. AUCTION_ENQUEUE_MSG(product_id) : ENQUEUE_REQUEST_MSG_T prośba oferenta o dopisanie go do listy osób zarejestrowanych w aukcji wystawcy przedmiotu (product_id). 6. AUCTION_ENLISTED_CONFIRMATION_MSG() : LEADING_PRICE_MSG_T przekazanie Oferentowi jego identyfikatora oraz aktualnej ceny danego przedmiotu. 7. AUCTION_OFFER_MSG(ID,price) : NEW_OFFER_MSG_T oferta oferenta zakupu przedmiotu (numer zaszyty w ID - identyfikatorze) od wystawcy po cenie (price). 8. INFO_NEW_PRICE_MSG(ID,price) : LEADING_PRICE_MSG_T wystawca informuje oferenta przedmiotu (zaszyte w ID) o jego nowej cenie (price) jest to zarazem potwierdzenie pozytywne dla oferenta który zgłosił cenę price. 7/12

8 9. INFO_AUCTION_CLOSED_MSG(ID,is_finished,price) : LEADING_PRICE_MSG_T wystawca informuje oferentów o zakończeniu aukcji przedmiotu (zaszyty w ID) po cenie (price). 10. NEGATIVE_CONFIRMATION_MSG(ID,msg_nr) : NEGATIVE_CONFIRMATION_MSG_T potwierdzenie negatywne skierowane do użytkownika odnośnie przedmiotu (zaszytego w ID) w odpowiedzi na komunikat msg_nr. UWAGA: Oferent, który chce zapisać się na aukcje wysyłając komunikat AUCTION_ENQUEUE_MSG z niepoprawnym numerem product_id otrzymuje potwierdzenie negatywne.. jednak z pustym ID bo przecież go nie jeszcze dostał. UWAGA2: Oferent, który posługuje się zbyt starą wersją protokołu również otrzyma potwierdzenie negatywne w odpowiedzi na komunikat: AUCTION_ENQUEUE_MSG z pustym ID. 11. AUCTION_RESULT_REQ_MSG(product_id): AUCTION_RESULT_REQ_T Za pomocą tego komunikatu użytkownicy mogą dowiedzieć się o wynikach aukcji UWAGA: Zobacz timeout'y w fazie II UWAGA2: Tu nie ma identyfikatora (wynika to z wykorzystania tego komunikatu w timeoutach). 8/12

9 8. Timeout-y standardowy timeout: 5s (rozdział Numerki) Timeout następujący w pierwszej fazie Z uwagi na niezobowiązujący charakter wymiany komunikatów w fazie pierwszej ewentualne wystąpienie timeout'u nie powoduje żadnych następstw. Oferent w fazie pierwszej nie uzyskawszy odpowiedzi na pytanie może je po prostu retransmitować. Timeout następujący w drugiej fazie Jeśli timeout wystąpi w fazie drugiej Oferent po stronie Wystawcy jest skreślany z listy chętnych na dany przedmiot. W celu ponownego dołączenia się do listy chętnych Oferent musi nawiązać połączenie oraz wysłać komunikat AUCTION_ENQUEUE_MSG (jeśli chce dalej podbijać cenę). Jeśli zacznie podbijać cenę zanim ponownie zgłosi się na aukcje dostanie negatywne potwierdzenie z błędem WRONG_ID. Problem pojawia się, gdy pomiędzy wystąpieniem timeout'a i powtórnym przyłączeniem się oferenta do aukcji Wystawca zdecyduje się na zakończenie aukcji. W takim wypadku Oferent przy próbie przyłączenia się do aukcji w/w komunikatem dostanie negatywne potwierdzenie z błędem AUCTION_IS_CLOSED. Jeśli użytkownik nie podbijał ceny produktu bądź odebrał komunikat LEADING_PRICE_MSG z nie swoją ceną po tym jak sam próbował (z sukcesem bądź nie) podbić cenę, to wiemy że on na pewno nie wygrał aukcji. W przeciwnym wypadku Oferent powinien dowiedzieć się czy przypadkiem to nie on wygrał aukcje. Oferent wysyła wtedy komunikat AUCTION_RESULT_REQ(bez Identyfikatora, bo wydawanie identyfikatorów na dany przedmiot kończy się wraz z zakończeniem aukcji). W odpowiedzi Wystawca retransmituje komunikat kończący aukcję (ten sam którym poinformował wszystkich innych Oferentów o zakończeniu aukcji). Na podstawie tego komunikatu użytkownik może dowiedzieć się, czy to on wygrał aukcje. Protokół nie zakłada zmiany zwycięzcy aukcji z powodu utraty połączenia z nim i braku prób powtórnego połączenia. 9/12

10 9. Opis stanów 1. Opis stanów z perspektywy użytkownika biorącego udział w aukcji. Diagram stanów widziany jest z perspektywy pojedynczej aukcji. Użytkownik powinien mieć możliwość równolegle brać udział w wielu aukcjach, oraz dodatkowo przedmioty tych aukcji mogą być w tym samym momencie w różnych fazach. 10/12

11 2. Opis stanów z perspektywy wystawcy. Diagram przedstawia stany i przejścia widziane z perspektywy pojedynczego przedmiotu wystawianego przez Wystawce. Wystawca może wystawiać wiele przedmiotów jednocześnie i różne przedmioty mogą być w różnych fazach w tym samym czasie. Jedyne ograniczenie jest takie, by Wystawca wysyłał potwierdzenia negatywne (z pustym ID) do oferentów którzy chcą się zapisać na listę na dany product_id, gdy ten jest jeszcze w fazie I. (na tym diagramie celowo pomijam timeouty, te zostały opisane w innym rozdziale) 11/12

12 10. Numerki 1. Numery Komunikatów msg_id 0x x x x x x x x x x x000A00 komunikat REQUEST_ITEMS_LIST_MSG REQUEST_ITEM_DETAIL_MSG ANSWER_ITEMS_LIST_MSG ANSWER_ITEM_DETAIL_MSG AUCTION_ENQUEUE_MSG AUCTION_ENLISTED_CONFIRMATION_MSG AUCTION_OFFER_MSG INFO_NEW_PRICE_MSG INFO_AUCTION_CLOSED_MSG NEGATIVE_CONFIRMATION_MSG AUCTION_RESULT_REQ_MSG 2. Błędy Numery błędów wraz z kolejnymi wersjami protokołu powinny być dopisywane na koniec a nie podmieniane (tak by numer błędu z kolejną wersją nie zmieniał swojego znaczenia).. Ewentualna podmiana znaczeń jest możliwa (!!! oprócz błędu PROTOCOLE_VERSION_NOT_SUPPORTED) ale może wiązać się z utratą kompatybilności wstecz (użytkownicy ze starszą wersją protokołu nie będą mogli uczestniczyć w aukcjach). Errno 1 PROTOCOLE_VERSION_NOT_SUPPORTED 2 WRONG_ID 3 PRICE_TOO_LOW 4 NO_SUCH_PRODUCT 5 AUCTION_IS_CLOSED 6 AUCTION_STILL_IN_STAGE_ONE 3. Inne Stałe Timeout: 5s 12/12