Notatki do specyfikacji protokołów Krzysztof Rządca Ostatnia modyfikacja: 30/05/2011 19:05 Za uwagi i pytania dziękuję panom Michałowi Czerskiemu, Jackowi Jendrejowi, Krzysztofowi Królakowi, Adamowi Michalikowi i pani Jadwidze Sosnowskiej. Ogólnie: Specyfikacja RQP zawiera więcej komunikatów, więc jej implementacja będzie nieznacznie trudniejsza niż implementacja protokołu Cytaty. Będę to brał pod uwagę oceniając zadania. Biblioteka klienta ma być thread-safe, tzn. może być używana jednocześnie przez wiele wątków jednego procesu. Można zakładać "współczesne" wersje języków programowania. Można zakładać, że klient i serwer działają pod linuksem. Zarówno klient, jak i serwer, muszą być przygotowane na odbiór komunikatów niepoprawnych lub złośliwych. Odebranie takiego komunikatu można sygnalizować lokalnemu użytkownikowi. Natomiast błędny komunikat nie może spowodować niepoprawnego działania serwera (zawieszenie się, koniec procesu, itp.), czy klienta (poza zgłoszeniem niepoprawnego formatu odpowiedzi). Podział cytatów na fragmenty nie musi być zrobiony już w bazie cytatów (specyfikacja protokołu nie powinna tego określać). Cytat może zawierać dowolne znaki oprócz \0; w szczególności znak nowej linii może być częścią cytatu (by móc wysyłać poezję!). Proszę o przesłanie Państwa rozwiązania emailem z tytułem "SK - projekt". Cały kod powinien znajdować się w katalogu login-ze-students_imie_nazwisko/ . Cytaty: 4.1: zamiast formatu ASCII proszę przyjąć UTF-8 4.2.1 i 6: KEY = 15 , NUMBER_KEY = 240 (a nie, odpowiednio, 621 i 923) 4.2.1: typ komunikatu to REQUEST_MSG_NUMBER_T (a nie REQUEST_MSG_NUMER_T) 4.2.2: string_len bierze pod uwagę '\0' kończące quote, czyli dla quote="abc" string_len=4 4.2.2: quote_id jest typu uint32 (a nie uint8) 4.2.2: pole quote_checksum wygodniej będzie traktować jako: uint8 quote_checksum[16] 5.2, stan WAIT_MORE: packet_id -> quote_id , sprawdzenie polega na porównaniu z wartością otrzymaną w pierwszym pakiecie quote_checksum nie jest sprawdzane w tym stanie RQP: 5.1: nazwa kodowania tekstu (pole encoding) zgodna jest z nazwami MIME ( http://www.iana.org/assignments/character-sets/ - preferred MIME name ) 5.1 i 7: Wszystkie części jednego cytatu mają to samo kodowanie (wartość pola encoding). 5.1: part_no w QDATA_T jest numerowany od 0. 5.2, 7.1.1: Przydział request_id przez klienta: ponieważ protokół wymusza numery unikalne (w ramach jednej instancji klienta), proszę przyjąć, że request_id jest kolejnym (sekwencyjnym) numerem żądania, liczonym od 0. Proszę uważać na wielowątkowość (biblioteka ma być thread-safe). 5.1: Pole error_buf w ERROR_T zawiera tekstowy opis błędu (po angielsku, kodowanie ASCII) 5.1: Pole encoding w QDATA_T, gdy nazwa kodowania jest krótsza niż 24 znaki, jest uzupełniane przez '\0'. (Co najmniej raz) Zadawane Pytania: > Czy za poprawną implementację protokołu Cytaty będzie można również > otrzymać maksymalną ilość punktów? Tak. Za Cytaty można dostać maksimum punktów. Przy ocenianiu będę brał pod uwagę to, że Cytaty są prostsze, więc gdy będę miał bardzo podobne implementacje Cytatów i RQP (w sensie architektury, zastosowanych rozwiązań w celu zwiększenia wydajności serwera, itd.), to wyżej ocenię RQP. Ale lepsza implementacja Cytatów będzie oceniona wyżej niż (lub tak samo jak) gorsza implementacja RQP. > Czy wystarczającym interfejsem użytkownika jest konsola? Tak, jeśli interfejs będzie spełniać specyfikację (m.in. serwer: możliwość dopisywania cytatów w trakcie działania serwera). > W jakich językach można pisać? W C, C++, Pythonie i Javie. > Czy planowane są jakieś testy wydajnościowe rozwiązań? Tak, będę testował wydajność serwera. Wyślę do serwera na raz dużą liczbę żądań i zmierzę liczbę odpowiedzi które doszły w określonym czasie (np. 1s, 5s, 10s).