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