PAI2009:: Protokół aukcji internetowych

Transkrypt

1 PAI2009:: Protokół aukcji internetowych Wojciech Łobacz 2 maja 2009 Streszczenie Projekt protokołu do obsługi aukcji internetowych, w którym komunikacja odbywa się bez udziału centralnego serwera, a wszyscy użytkownicy protokołu są równouprawnieni i mogą wystawiać na akucje własne przedmioty oraz brać udział w aukcjach przedmiotów wystawionych przez innych użytkowników. 1

2 Spis treści 1 Wprowadzenie Opis celów protokołu Terminologia Opis założeń protokołu Protokoły transportu Model komunikacji Opis formatu komunikatów Założenia: Pomocnicze typy danych Komunikaty w ramach kanału informacyjnego Komunikaty w ramach kanału licytacyjnego Opis wymienianych komunikatów Komunikaty w ramach kanału informacyjnego Komunikat typu: MSG_POLL Komunikat typu: MSG_QUESTION Komunikat typu: MSG_TENDER Komunikat typu: MSG_DETAILS Komunikat typu: MSG_ATTACHMENT Komunikat typu: MSG_REFUSE_ATTACHMENT Komunikat typu: MSG_WANT_ATTACHMENT Komunikaty w ramach kanału licytacyjnego Komunikat typu: MSG_START Komunikat typu: MSG_BID Komunikat typu: MSG_END Komunikat typu: MSG_CONFIRM Komunikat typu: MSG_REFUSAL Komunikat typu: MSG_INFO Opis stanów Wprowadzanie Perspektywa kanału licytacyjnego - sprzedający Diagram Opis stanów diagramu Perspektywa kanału licytacyjnego - kupujący Diagram Opis stanów diagramu Perspektywa kanału informacyjnego - sprzedający Diagram

3 5.4.2 Opis stanów diagramu Perspektywa kanału informacyjnego - kupujący Diagram Opis stanów diagramu Podsumowanie używanych numerów 18 3

4 1 Wprowadzenie Niniejszy dokument opisuję specyfikację protokołu internetowych aukcji. Składa się z następujących części: Opis założeń protokołu Opis formatu komunikatów Opis wymienianych komunikatów Opis stanów Podsumowanie używanych numerów 1.1 Opis celów protokołu Celem protokołu jest umożliwienie przeprowadzania aukcji internetowych. W modelu komunikacji wszyscy użytkownicy mają równe prawa. Mogą zarówno licytować wystawione przedmioty jak i je sprzedawać. Do obsługi wymienionych czynności użytkowników zbędny jest serwer centralny. Cele nadrzędne: umożliwienie sprzedaży przedmiotu umożliwienie zakupu przedmiotu Cele drugorzędne: prostota łatwość rozszerzenia o nowe funkcjonalności 1.2 Terminologia w nieniejszym dokumencie używane są dokładnie określone definicje, których znaczenie w późniejszych wystąpieniach znajduję się poniżej: obiekt sprzedaży licytowany przedmiot/usługa licytacja proces, w którym sprzedający (zdefiniowany dalej) oferuje obiekt sprzedaży, a inni użytkownicy poprzed oferowanie coraz to większych kwot starają się go pozyskać poprzez zaproponowanie najwyższej ceny. sprzedający osoba, do której należy obiekt sprzedaży 4

5 licytujący osoba biorą udział w licytacji, czyli osoba która zgłosiła swój udział w aukcji danego obiektu sprzedaży oraz otrzymała potwierdzenie zapisania się do licytacji przez sprzedającego kanał informacyjny czynności związane z licytacją takie jak: Zapytanie o obiekty sprzedaży Odpowiedz na zapytanie o obiekty sprzedaży Zapytanie o cechy obiektu sprzedaży Odpowiedz na zapytanie o cechy obiektu sprzedaży kanał licytacyjny czynności związane z licytacją takie jak: Zapisanie się na licytację Licytowanie Informowanie o akutalizacji obecnej najwyższej ofercie danego obiektu sprzedaży Zakończenie licytacji, rozesłanie wyników licytacji 2 Opis założeń protokołu 2.1 Protokoły transportu Ze względu na odmienny charakter oraz cele stawiane przed kanałem licytacyjnym oraz kanałem informacyjnym wprowadza się dwie różne protokoły transportu danych dla wyżej wymionych kanałów. Kanał licytacyjny będzie korzystał z protokołu TCP, natomiast kanał informacyjny używać będzie protokołu UDP. Protokół UDP jako odnaczający się mniejszym kosztem lepiej nadaje się do rozsyłania podstawowych komunikatów informacyjnych, gdzie dopuszczalne jest zagubienie się jakiego komunikatu. W przypadku kanału licytacyjnego wymagana jest większa pewność dochodzenia przesyłanych komunikatów jak i ścisła identyfikacja, dlatego też wybrany został protokół TCP. 2.2 Model komunikacji Ze względu iż wszyscy użytkownicy są sobie równi, wszyscy mogą zarówno licytować jak i sprzedewać (a zatem jednocześnie funkcjonować jako serwer i klient), wybranym modelem komunikacji w sieci będzie P2P. Podczas wymiany komunikatów w kanale licytacyjnym połączenie jest tworzone po stronie sprzedającego (działającego jako serwer), a kupujący funkcjonują jako klienci. W przypadku niezgodności zaistniałych po stronie klienta takich jak np. TIME- OUT, sprzedający zamyka połączenie z danym użytkownikiem - przestaje on być automatycznie uczestnikiem aukcji. W fazie informacyjnej schemat komunikacji jest bardzo podobny. Strona zainteresowana obiektami sprzedaży wysyła zapytania do sprzedającego. Okres oczekiwania wyznaczona TIMEOUT. Po przekroczeniu tego czasu klient może ponowić komunikat albo zrezygnować z uzyskania informacji. 5

6 3 Opis formatu komunikatów 3.1 Założenia: Porządek octetów w liczbach: sieciowy, sposób interpretacji liczb ze znakiem: jak w arytmetyce uzupełnień do Pomocnicze typy danych DATA_T{ uint32 data_length; octet[data_length] data; } data_length pole określające rozmiar danych tablicy data. W przypadku gdy wartość pola wynosi 0, pole data nie występuje. OBJECT_T{ uint16 id; uint32 data_length; octet[data_length] data; } id pole zawierającej identyfikator obiektu sprzedaży/aukcji. data_length pole określające rozmiar danych tablicy data. W przypadku gdy wartość pola wynosi 0, pole data nie występuje. 3.3 Komunikaty w ramach kanału informacyjnego Komunikaty użyte w kanale informacyjnym mają następującą postać: MSG_INF{ uint16 version; uint32 timestamp; uint8 type; uint8 n;? arg1;...? argn; } Znaczenia poszczególnych pól w strukturze należy rozumieć następująco: 6

7 version numer wersji protokołu timestamp data wysłania wiadomości, składa się z roku, miesiąca, dnia, godziny, minuty i sekundy type określa typ komunikatu n określa liczbę argumentów przesłanych w komunikacie arg1... argm kolejne argumenty komunikatu, o typie zdefiniowanym w zależności od wartości komunikatu type. 3.4 Komunikaty w ramach kanału licytacyjnego Schemat komunikatu ma następującą strukturę: MSG_BIDD{ uint13 version; DATA_T id; uint16 bidid; uint16 msgid; uint32 timestamp; uint8 type; uint8 n;? arg1;...? argn; } Znaczenia poszczególnych pól w strukturze należy rozumieć następująco: version numer wersji protokołu id identyfikator użytkownika, stworzony na podstawie przesłanej przez licytującego NAZWY_UZYTKOWNIKA oraz IP, PORTU licytującego. bidid identyfikator obiektu sprzedaży nadawany przez sprzedajacego niezależnie od otrzymanych danych (np. generowany na podstawie daty wystawienia obiektu sprzedaży - zakładając, że nie jest możliwe wystawienie na aukcji 2 obiektów sprzedaży w jednym momencie), które przesłał licytujacy. Może być również utożsamiany jako identyfikator aukcji. msgid unikalny identyfikator komunikatu dla każdego komunikatu timestamp data wysłania komunikatu 7

8 type określa typ komunikatu n określa liczbę argumentów przesłanych w komunikacie arg1... argm kolejne argumenty komunikatu, o typie zdefiniowanym w zależności od wartości komunikatu type. 4 Opis wymienianych komunikatów 4.1 Komunikaty w ramach kanału informacyjnego Komunikat typu: MSG_POLL MESSAGE HEADER version timestamp POLL 0x00 Komunikat sondażowy. Znaczy tyle co prośba o informacje o trwających licytacjach Komunikat typu: MSG_QUESTION MESSAGE HEADER ID QUESTION version timestamp QUESTION 0x02 uint16 DATA_T Komunikat będący pytaniem o szczególy obiektu sprzedaży idenfytikowanego przez ID. Treść zapytania jest przekazywana w ostatnim polu QUESTION Komunikat typu: MSG_TENDER MESSAGE HEADER OBJECT_0... OBJECT_N-1 version timestamp TENDER N+1 OBJECT_T OBJECT_T OBJECT_T Komunikat zawierający informacje o oferowanych przez użytkownika obiektów sprzedaży. Pole n z nagłówka określa ile jest obiektów sprzedażych, natomiast kolejne pola OBJECT_T zawierają opisy poszczególnych obietków sprzedaży oraz ich identyfikatory, które generuje licytujący. Będą one obowiązywały podczas całego przebiegu aukcji. Wartość zero oznacza brak wystawionych obiektów sprzedaży. Jest to jedyny typ komunikatu gdzie pole n nie ma ustalonej niezmiennej wartości Komunikat typu: MSG_DETAILS MESSAGE HEADER ID ANSWER ATTACHMENT_SIZE MSG_ID version timestamp DEATAILS 0x04 uint16 DATA_T uint16 uint32 8

9 Komunikat będący szczegółową odpowiedzą na pytanie dotyczące obiektu sprzedaży identyfikowanego przez ID. Jeśli możliwe jest dołączenie załącznika to w polu ATTACHMENT_SIZE jest ustawiony jego rozmiar. Pole MSG_ID zawiera identyfikator wiadomości, którą trzeba przekazać w przypadku zdecydowania się na pobranie załącznika Komunikat typu: MSG_ATTACHMENT MESSAGE HEADER ATTACHMENT_TYPE ATTACHMENT version timestamp ATTACHMENT 0x02 uint32 DATA_T Komunikat przechowujący w sobie załącznik w polu ATTACHMENT typu ATACHMENT_TYPE. Odnosi się do obiektu sprzedaży identyfikowanego przez ID Komunikat typu: MSG_REFUSE_ATTACHMENT MESSAGE HEADER MSG_ID version timestamp ATTACHMENT 0x01 uint32 Komunikat odmawiający przyjęcia załącznika Komunikat typu: MSG_WANT_ATTACHMENT MESSAGE HEADER MSG_ID version timestamp ATTACHMENT 0x01 uint32 Komunikat oznajmiający chęć pozyskania załącznika. Pole MSG_ID zawiera identyfikator wiadomości, w której był oferowany załącznik. 4.2 Komunikaty w ramach kanału licytacyjnego Krążące komunikaty w obrębie protokołu można scharakteryzować względem następującego podziału: Komunikat typu: MSG_START MESSAGE HEADER NAZWA version emptyid bidid msgid timestamp START 0x01 DATA_T Komunikat odpowiadający prośbie o zapisanie się do licytacji przedmiotu, którego identyfikator jest przekazany jako bidid. Dodatkowo przekazujemy parametr NAZWA, który zostanie użyty do stworzenia unikalnego identyfikatora dla zgłszającego się. Pondadto należy zwrócić uwagę na wartość emptyid. Jest to struktura DATA_T z polem data_length ustawionym na 0. 9

10 4.2.2 Komunikat typu: MSG_BID MESSAGE HEADER CENA version id bidid msgid timestamp BID 0x01 uint16 Komunikat określający kto (id) składa ofertę o wartości CENA na określony poprzez pole bidid obiekt sprzedaży Komunikat typu: MSG_END MESSAGE HEADER CENA version id bidid msgid timestamp END 0x01 uint16 Komunikat zawiadamiający o zakończenu aukcji. Zawiera w sobie w polu CENA najwyższą przyjętą kwotę zaoferowaną za dany obiekt sprzedaży Komunikat typu: MSG_CONFIRM MESSAGE HEADER REQ_ID version id bidid msgid timestamp CONFIRM 0x01 uint16 Komunikat będący odpowiedzią pozytywną na komunikat wysłany od licytującego. Pole REQ_ID określa na który konkertnie komunikat odpowiadamy twierdząco Komunikat typu: MSG_REFUSAL MESSAGE HEADER REQ_ID REASON version id bidid msgid timestamp REFUSAL 0x02 uint16 DATA_T Komunikat będący odpowiedzią negatywną na wcześniej otrzymany. Pole REQ_ID określa komunikat, którego tyczy się potwierdzenie negatywne, natomiast pole REASON jest uzasadnieniem negatywnej odpowiedzi (tekstem) Komunikat typu: MSG_INFO MESSAGE HEADER CURRENT_PRIZE version id bidid msgid timestamp INFO 0x01 uint16 Komunikat będący informacją o zmianie aktualnej ceny obiektu sprzedaży. Pole bidid określa obiekt sprzedaży, którego tyczy się komunikat. 10

11 5 Opis stanów 5.1 Wprowadzanie Ze względu na diametralnie różne punkty widzenia protokołu przez sprzedającego i licytujacego oraz różnice pomiędzy kanałem informacyjnym, a licytacyjnym, zostanie przedstawiony opis stanów uwzględniący właśnie taki podział na perspektywy, a mianowicie: perspektywa kanału licytacyjnego perspektywa sprzedającego perspektywa licytującego perspektywa kanału informacyjnego perspektywa sprzedającego perspektywa licytującego Należy zauważyć, iż wymienione perspektywy mogą być traktowane niezależnie tj. w przypadku gdy użytkownik będzie pełnił podwójną rolę, czyli jednocześnie licytował i sprzedawał, to oba przedstawione opisy stanów pozostaną aktualne. Na diagramach stosowana jest jednolita konwencja dla ilustracji stanów, komunikatów wysyłanych oraz komunikatów odbieranych. Przykłady poniżej: Rysunek 1: Konwencja oznaczeń. UWAGA1: Na diagramie komunikatu odpowiedzi zostały przedstawione dla uproszczenia jako jeden wychodzacy komunikat z podpisem ANSWER. W opisach stanów pod diagramem znajduja się informacje, czy dany komunikat jest odpowiedzia negatywna czy pozytywna. UWAGA2: We wszystkich sytuacjach gdy oczekujemy na potwierdzenie, to jeśli nie otrzymamy go przed upływem ustalonego TIMEOUT to zachowujemy się jakbyśmy otrzymali komunikat negatywny. 5.2 Perspektywa kanału licytacyjnego - sprzedajacy Diagram Niniejszy obrazek przedstawia diagram stanów widziany z perspektywy sprzedającego: 11

12 Rysunek 2: Perspektywa klienta. 12

13 5.2.2 Opis stanów diagramu Poniżej zostały zebrane uwagi i komentarze przy stanach, które tego wymagają. IDLE_STATE stan, który można określić stanem neutralnym lub stanem głownym, gdyż z tego stanu jest obsługiwana największa część komunikatów tj. reagowanie na przyjście komunikatów typu MSG_START oraz MSG_BID oraz będąc w tym stanie można zakończyć licytację. W przypadku otrzymania komunikatu: MSG_START rozpatrujemy zgłoszenie chęci uczestnicwa użytkownika i wysyłamy potwierdzenie lub odrzucenie prośby. Warunki przyjęcia/odrzucenia nie wchodzą w ramy niniejszego dokumentu. Po akceptacji zgłoszenia, użytkownikowi zostaje wygenerowany ID na podstawie jego IP, PORTU oraz NAZWY_UZYTKOWNIKA, którą załączył w komunikacie. Gdyby okazało się, że stworzony idenfitykator jest identyczny z wcześniej już używanym, odsyłany jest komunikat MSG_REFUSAL, zawierający w uzasadnieniu odmowy informację o przyczynie odrzucenia prośby o akceptaję udziału w aukcji. Po wygenerowaniu ID odsyłamy go użytkownikowi w komunikacie MSG_CONFIRM, w poluid, odpowiednio uzupełniając pole REQ_ID, które jest identyfikatorem komunikatu, którego tyczy się potwierdzenie. MSG_BID zostaje porównana zaoferowana cena z aktualną ceną obiektu sprzedaży. W przypadku wyższej oferty wysyłany jest komunikat MSG_CONFIRM potwierdzający przyjecie nowej oferty, a następnie do wszystkich użytkowników ( w tym aktualnego lidera licytacji) komunikatu MSG_INFO. W przypadku odmowy wysyłany jest komunikat MSG_REFUSAL, w którym może znaleźć się przyczyna odmowy. inny komunikat komunikat nie zostaje przetwarzany. W przypadku decyzji użytkownika o zakończeniu aukcji, jest rozsyłany do wszystkich użytkowników komunikat MSG_END zawierający zwycięska cenę przedmiotu. Następnie przyjmowany jest stan CONFIRM_STATE. TESTBID_STATE w tym stanie jest analizowany komunikat (MSG_BID) oferujący określoną kwotą za obiekt sprzedaży. W zależności od tego czy proponowana kwota przekracza aktualną cenę czy też nie, zostanie wysłany komunikat odmowy (MSG_REFUSAL) lub też potwierdzenie zaakceptowania nowej kwoty oraz rozesłanie do wszystkich uczestników aukcji informacji o nowej cenie obiektu sprzedaży. CONFIRM_STATE stan, w którym czekamy na potwierdzenia od wszystkich licytujących. Jeśli po upływie czasu, określonego stałą TIMEOUT nie nadejdzie potwierdzenie od licytującego, to przyjmujemy, że licytujący zrezygnował z aukcji i w tym momencie, aby jeszcze raz móc głosować będzie zmuszony do ponownego złoszenia sprzedającemu swojej chęci uczestnictwa. W tym stanie przyjmowane są tylko komunikaty MSG_CONFIRM. START_STATE stan do którego przechodzi się po otrzymaniu od klienta komunikatu wyrażającego chęć przystąpienia do licytacji (MSG_START). W przypadku odmowy wysyłany 13

14 jest komunikat (MSG_REFUSAL) stan do którego przechodzi się po otrzymaniu od klienta komunikatu wyrażającego chęć przystąpienia do licytacji (MSG_START). W przypadku odmowy Przy nadejściu komunikatu niewyszczególnionego w danym stanie, przyjmuje się, że zostanie on w danym momencie zingorowany, a jego obsłużeniem zajmiemy się w stanie IDLE_STATE. 5.3 Perspektywa kanału licytacyjnego - kupujacy Diagram Rysunek 3: Perspektywa klienta Opis stanów diagramu Stany, które wystąpiły na diagramie wymagają chociażby skrótego opisu, będącego jednocześnie uzasadnieniem ich wyszczególnienia oraz komentarzem je opisującym. IDLE_STATE stan podstawowy, w którym użytkownik nie bierze udziału w aukcji. (UWAGA: opis stanu tyczy się tylko komunikacji w obrębie kanału licytacyjnego). W tym stanie przyjmowane są następujące komunikaty: MSG_TENDER omówione dalej (patrz: 5.5.2) MSG_DETAILS omówione dalej (patrz: 5.5.2) 14

15 CONFIRM_STATE stan, w którym jesteśmy zaraz po wysłaniu komunikatu o chęci przystąpienia do licytacji i oczekujemy na potwierdzenie od sprzedającego. W zależności od odpowiedzi (albo negatywnej MSG_REFUSAL albo pozytywnej MSG_COMMIT) będziemy mogli brać udział w aukcji lub zostaniemy dalej w stanie IDLE_STATE. BID_STATE będąc w tym stanie użytkownik jest pełnoprawnym uczestnikiem aukcji. Bedąc w tym stanie otrzymuje komunikaty informujące o zwiększeniu się cenie aktualnej przedmiotu sprzedaży jak i o zakończeniu aukcji. INFO_CONFIRM_STATE w tym stanie znajdujemy się po otrzymaniu komunikatu o nowej aktualnej cenie, co musimy potwierdzić stosownym komunikatem MSG_CONFIRM. BID_CONFIRM_STATE w tym stanie oczekujemy na potwierdzenie wysłanej wiadomości z propozycją nowej najwyższej oferty kupna obiektu sprzedaży. 5.4 Perspektywa kanału informacyjnego - sprzedajacy Diagram Rysunek 4: Kanał informacyjny Opis stanów diagramu W obrębie kanału informacyjnego można wyróżnić stany: IDLE_STATE w obrębie kanału informacyjnego przyjmowane są wiadomości: MSG_POLL pytanie o wystawione na licytacji obiekty sprzedaży. Wysyłany jest wtedy komunikat MSG_TENDER zawierający aktualną ofertę sprzedającego. 15

16 MSG_QUESTION pytanie o konkretny obiekt sprzedaży. Wysyłany jest wtedy komunikat MSG_DETAILS zawierający odpowiedz na zadane pytanie. W przypadku gdy do odpowiedzi przewidziane jest dołączenie pliku, ustawione jest odpowiednie pole w wysłanym komunikacie, a protokół przechodzi do stanu ATTACHMENT_WAIT_STATE, gdzie oczekuje na komunikat od licytujacego. W przypadku braku załącznika protokół po wysłaniu wiadomości zostaje dalej w tym samym stanie. ATTACHMENT_WAIT_STATE stan, w którym oczekujemy na decyzję licytującego odnośnie chęci otrzymania załącznika. W przypadku MSG_REFUSE_ATTACHMENT załącznik nie jest wysyłany, a protokół przechodzi w stan IDLE_STATE. Ów stan jest również osiągany w przypadku gdy czas oczekiwania na odpowiedz licytującego przekroczy TIMEOUT. W przeciwnym razie osiągany jest stan ATTACHMENT_SEND_STATE. ATTACHMNET_SEND_STATE w tym stanie nastąpi przesłanie załącznika. Z wykonaniem ten czynności przenosimy się do stanu IDLE_STATE 16

17 5.5 Perspektywa kanału informacyjnego - kupujacy Diagram Rysunek 5: Kanał informacyjny Opis stanów diagramu W obrębie kanału informacyjnego można wyróżnić stany: IDLE_STATE w obrębie kanału informacyjnego przyjmowane są wiadomości: MSG_TENDER informacje o obiektach sprzedaży użytkownika MSG_DETAILS informacje o konkretnym obiekcie sprzedaży użytkownika. W przypadku gdy oferowany jeste załącznik o niezerowym rozmiarze, protokół przechodzi do stanu ATTACHMENT_STATE. ATTACHMENT_STATE stan, w którym nie są pobierane żadne komunikaty. Stan odpowiada sytuacji, gdy otrzymaliśmy powiadomienie o czekającym na dedycję dostarczenia załączniku. W zależności od chęci użytkownika pobrania lub odrzucenia możliwości pobrania załącznika, należy wysłać odpowiednio komunikat MSG_WANNT_ATTACHMNET lub REFUSE_ATTACHMENT ATTACHMENT_WAIT_STATE stan, w którym klient oczekuje na komunikat ATTACHMENT. Po otrzymaniu tego komunikatu lub przekroczeniu TIMEOUTU przechodzi do stanuidle_state. 17

18 6 Podsumowanie używanych numerów W opisie protokołu używane są określone stałe, których wartości znajdują się w poniższej tabeli: POLL = 1 QUESTION = 2 TENDER = 3 DETAILS = 4 START = 5 BID = 6 END = 7 CONFIRM = 8 REFUSAL = 9 DESC_SIZE = 1000 TIMEOUT = 10s (proponowane) 18