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).