- kończenie komunikatów głosowych zerem jest złym pomysłem (głos to dane binarne i trzeba je będzie specjalnie zakodować przed wysłaniem i odkodować po odebraniu; lepiej jest mieć dodatkowe pole "długość komunikatu") + znacznik czasowy w komunikacie głosowym - projekt protokołu nie powinien narzucać implementacji za pomocą wątków ~ jeśli NIC_NIE_ROBIE_STATE jest charakterystyczny dla użytkownika, dlaczego błąd w jednym połączeniu (przy utrzymaniu innych) powoduje przejście do tego stanu? (to jest chyba tylko trochę niejasno napisane, nie mam formalnych zastrzeżeń) + ładny i czytelny diagram stanów ~ czyim obowiązkiem jest utworzenie połączeń TCP i UDP na wskazanych portach w CHCE_ZADZWONIC_STATE / KTOS_CHCE_ZADZWONIC_STATE ? - co to znaczy "zarezerwować porty"? Jedyna sensowna z praktycznego punktu widzenia interpretacja polega na utworzeniu słuchających gniazd TCP i UDP po jednej stronie (chyba lepiej u dzwoniącego, na dowolnych wolnych portach), do których podłączy się druga strona używając już dowolnych portów. Wtedy komunikat PRZYJECIE_POLACZENIA_MSG faktycznie może zawierać numery portów, które trafiły się odbierającemu, ale raczej nie ma to sensu. + poprawna obsługa dwustronnej próby zawieszenia + skuteczna synchronizacja + implementowalność Ocena: 4.5