- o liczbie WLT Wiele osób zdecydowało się ograniczyć liczbę WLT przez 256. Jest to jeden z przykładów jeszcze zakorzenionego w nas przeświadczenia, że należy oszczędzać pamięć, gdzie się da. Proszę jednak zauważyć, że sam rozmiar nagłówków IP i TCP, które są w każdym pakiecie, to kilkadziesiąt bajtów. Zwiększenie rozmiaru numerów WLT z 1 na 2 bajty nie jest więc tragedią. Projektanci IP założyli kiedyś, że 32 bity na adres internetowy w zupełności wystarczą, ale mylili się. IP6 używa adresów 96-bitowych. Moja rada - gdy będą państwo projektować coś w przyszłości, proszę raczej zwracać uwagę na rozszerzalność i myśleć z rozmachem, niż oszczędzać każdy bajt. - o synchronizacji Dominującym podejściem do synchronizacji grupowej był krążący żeton. Zaletą jest prostota koncepcji i skuteczność, ale proszę pamiętać o narzucie, jaki to z sobą niesie, gdy każdy powinien mieć żeton przynajmniej 20-100 razy na sekundę. Jeśli członkowie grupy muszą komunikować się przez Internet, osiągnięcie takiej wydajności jest w ogóle niewykonalne. Optymalnym wyjściem jest coś w stylu algorytmu Ricarda-Agrawali, co w naszym przypadku wcale nie jest takie skomplikowane, gdy mamy założoną zerową awaryjność w grupie. W istocie, kilka udanych prób synchronizacji ad-hoc daje się sprowadzić do RA. Wiele osób wyłożyło się na jednoczesnej próbie zawieszenia połączenia przez obu rozmówców. Takie algorytmy przechodziły do stanu zawieszonego bez czekania na potwierdzenie. To dziwne, bo w jednym z maili specjalnie zwróciłem na to uwagę. - o transmisji głosu Tu zazwyczaj było OK. Do transmisji głosu należy używać UDP, nie TCP, ze względu na mniejsze narzuty i opóźnienia oraz dlatego, że utrata króciutkiego fragmentu rozmowy (a tylko takie są transmitowane, inaczej opóźnienia są za duże) jest lepszym wyjściem, niż czekanie, aż zabłąkany pakiet wreszcie dotrze. Buforowanie pakietów głosowych nie jest częścią protokołu. Czasem brakowało opisu, jak transmisja głosu w ogóle wygląda. Niektórzy z nieznanych dla mnie powodów zabronili przesyłania znaku '\0'. To w niczym nie ułatwia, a nagle sprawia, że implementacje muszą wymyślić sposób kodowania mowy, by ten znak się nie pojawiał. Sposób takiego kodowania musiałby być wówczas częścią projektu, by głos zakodowany przez jedną implementację mógł być odkodowany przez inną. - o łamaniu remisów Nie należy rozstrzygać konfliktów deterministycznie. Jeśli system miałby być stosowany np. w call-center, wszyscy pracownicy powinni być obciążeni w miarę równomiernie. Nie powinno być tak, że ktoś prawie nic nie robi, a ktoś inny odbiera telefon za telefonem. - o przejrzystości i kompletności Używanie krótkich (w skrajnych przypadkach - jednoliterowych) nazw na stany czy wiadomości praktycznie uniemożliwia zrozumienie, o co chodzi. Na szczęście większość osób stosowała się do konwencji z "zasad opisywania protokołów". Często spotykane i mile widziane były również słowne opisy do stanów i przejść między nimi. Z drugiej strony, często brakowało sposobu rozpoczynania komunikacji między dwoma stronami, gdy połączenie na WLT jeszcze nie istnieje. Z kompletnością nie należy popadać w przesadę. W sytuacji, gdy implementacja może zrobić coś mądrze i gdy odgórna decyzja jest trudna i jaka by nie była, pewnie będzie nieoptymalna, a nie jest kluczowa do działania protokołu, dobrym wyjściem jest pozostawienie jej implementatorom (najlepiej wyrażając to explicite). W szczególności należy tak czynić z decyzjami, które nie wpływają na kompatybilność implementacji między sobą, a do których podjęcia najlepiej wykonać jest wcześniej trochę eksperymentów. Implementatorom należy narzucać w protokole tyle, by różne implementacje były kompatybilne między sobą, i raczej nie więcej. W szczególności pisanie, że każdej rozmowie ma odpowiadać wątek jest kiepskim pomysłem. Implementacja oparta na funkcji select będzie działać tak samo z punktu widzenia komunikacji sieciowej, zużywając za to mniej zasobów systemowych. - o czytelności Osoby przysyłające pliki tekstowe powinny dbać, by dawały się one wygodnie czytać na innych komputerach. W szczególności oznacza to łamanie linii w rozsądnych granicach (80, góra 120 kolumn) i unikanie tabów. Proszę mi wierzyć, tekstowe diagramy otwierane na komputerze z innymi ustawieniami tabów, niż u autora, wyglądają dość zabawnie. Proszę też zwracać uwagę na ortografię i interpunkcję. Zwłaszcza to pierwsze jest tak łatwo zapewnić, przepuszczając tekst przez jakiegoś spell-checkera, że przysyłanie dokumentów z błędami jest wręcz niegrzeczne. (Ja się nie gniewam.) - o ocenianiu Projekty przygotowane przez Państwa mają być podstawą implementacji. Niektóre projekty, czy to z uwagi na nieczytelność, czy poważne błędy, mimo moich szczerych chęci nie mogły być określone jako "implementowalne". Projekty te dostały niskie oceny. W pozostałych przypadkach przymykałem oczy na wiele rzeczy i oceniałem raczej łagodnie. - o implementacji Do poniedziałku 21.05 mogą mi Państwo przysyłać uwagi odnośnie wybranych projektów. Uwagi mogą dotyczyć niejasności pewnych sformułowań, ale również i błędów w protokole (nawet w "najlepszych" pracach, w ich obecnej formie, może dojść do zakleszczeń). Jest to o tyle ważne, że wady protokołu wybranego do implementacji wpływają negatywnie na ocenę programów. Jedyny wyjątek to synchronizacja żetonem - nie jest idealna, ale nie będę za to obniżał. Do czwartku 24.05 autorzy wybranych projektów muszą uwzględnić moje zastrzeżenia. Za tą dodatkową pracę zostaną wynagrodzeni dodatkowymi punktami (maksymalnie można uzyskać 2 punkty).