S1) Algorytm Cristiana
-Ten serwer czasu jest najlepszy, dla którego czas odpowiedzi jest najmniejszy.
-Klient ustala swój czas na czas_otrzymany - 0.5*długość_czasu_odpowiedzi.
-Serwer czasu w ramach funkcji odpytującej o czas powinien: odczekać mały losowy odcinek czasu; pobrać dane z Zegara, odczekać mały, losowy odcinek czasu; zwrócić odpowiedź.
-Dobrze by było, gdyby klient sam zliczał czas algorytmem podobnym do algorytmu w zegarze, następnie po uaktualnieniu zegara wypisywał otrzymane różnice.

S3) Serwer heartbeat
-Klienci oczywiście muszą informować serwer, iż się włączają, ale nie powinni informować o sytuacji odwrotnej.
-W najprostszej implementacji klient wysyła w stałych odstępach czasu powiadomienie do serwera, że jest aktywny.

S4) Dostęp do sekcji krytycznej - algorytm pierścieniowy
-Każdy proces powinien posiadać osobny port do komunikacji, bądź inną etykietkę w RMI.

M1) 
Serwer co jakiś czas wysyła zapytanie o czas do wszystkich klientów. Następnie wylicza oszacowany czas (za pomocą algorytmu Cristiana) na wszystkich klientach (t_1...t_n). Później serwer przyjmuje czas docelowy (t_final) jako średnia z czasu własnego oraz oszacowanych czasów od klientów. Na końcu serwer rozsyła różnice między czasem docelowym (t_final) a oszacowanymi czasami na wszystkich klientach. Klienci po otrzymaniu poprawki aktualizują swój zegar.
M3) Algorytm Tyrana
- Każdy klient posiada swój niepowtarzalny numer określający jego priorytet (najlepiej by były to kolejne liczby naturalne).
- Każdy klient co jakiś czas sprawdza, czy koordynator działa. Jeżeli on działa to na jakiś czas klient zasypia. W innym wypadku Klient wysyła do wszystkich innych klientów sygnał ELEKCJA i czeka na sygnał zwrotny OK. Jeżeli nie otrzyma on ani jednej odpowiedzi, wtedy wysyła sygnał KOORDYNATOR do wszystkich klientów (i wypisuje stosowną informację na konsoli).
- Każdy klient powinien się w sposób losowy co jakiś czas wyłączać i włączać.

M4) Projekt ten należy pominąć.