Specyfikacja: Dynamiczny wybór źródła czasu w mechanizmie timestamp_mw

Specyfikacja: Dynamiczny wybór źródła czasu w mechanizmie timestamp_mw

1. Cel zadania

Przejście z modelu statycznego (sztywny adres masterIP) na model dynamiczny, w którym urządzenia automatycznie wybierają najlepsze źródło synchronizacji czasu na podstawie klasy urządzenia przesyłanej w ramce tinyNTP.

2. Architektura danych (ntpStruct)

Należy wykorzystać pole settings w strukturze ntpStruct do przesyłania metadanych o statusie urządzenia.

3. Wymagania Funkcjonalne

3.1. Konfiguracja i start

• Plik konfiguracyjny: Aplikacja musi wczytywać parametry z /opt/srp/cpu_simba/ntp_config.json.
  • Wymagane pola: ip, ntp_class (0-7), T_hb_ms (interwał ogłoszeń).
• Inicjalizacja: Podczas startu TimestampService musi zainicjalizować NtpController z uwzględnieniem klasy wczytanej z pliku. W przypadku błędnych danych w JSON należy zastosować fallback (np. klasa 7) i zalogować błąd.

3.2. Mechanizm Discovery (Multicast)

• Rozgłaszanie: Każde urządzenie musi co interwał T_hb_ms wysyłać ramkę Announce na adres/port UDP Multicast.
• Baza sąsiadów: Urządzenie utrzymuje listę aktywnych węzłów (IP, klasa, czas ostatniej aktywności).
• Zarządzanie listą:
  • Wpisy starsze niż 15 sekund muszą być automatycznie usuwane.
  • Urządzenie nie dodaje własnego adresu IP do listy kandydatów.

3.3. Algorytm wyboru źródła (Best Master Clock)

Przed każdą sesją synchronizacji urządzenie analizuje listę dostępnych węzłów i wybiera źródło według priorytetów:

1. Najniższa klasa (deviceClass): Im mniejsza wartość, tym lepsze źródło.
2. Status Holdover: Preferowane są urządzenia z bitem holdover = 0.
3. Tie-breaker: W przypadku identycznej klasy i statusu, wybierane jest urządzenie o niższym adresie IP.

Logika Ról:

• Jeśli lokalne urządzenie posiada najwyższy priorytet na liście -> pracuje jako Serwer.
• W przeciwnym wypadku -> pracuje jako Klient i synchronizuje się do wybranego lidera.

3.4. Integracja z tinyNTP

• Utrzymanie obecnej logiki obliczania przesunięcia czasu (offset) i RTT na podstawie znaczników t0..t3.
• Dynamiczne uzupełnianie pola settings we wszystkich wychodzących ramkach (zarówno Unicast, jak i Multicast).

4. Kryteria Akceptacji (AC)

• Brak statycznego IP: Usunięcie zależności od zmiennej masterIP w kodzie.
• Prawidłowe mapowanie: Potwierdzenie bitowego zapisu/odczytu klasy i flagi holdover w settings.
• Obsługa błędów: System poprawnie reaguje na brak pliku konfiguracyjnego lub błędy w JSON.
• Dynamiczna zmiana: Po wyłączeniu urządzenia o najwyższym priorytecie (klasa 0), pozostałe urządzenia w sieci w ciągu max 15s wybierają nowe źródło (np. klasa 1).
• Stabilność: Proces synchronizacji nie ulega przerwaniu przy zmianie roli z Serwera na Klienta.