8. Algorytm elekcji

[kontrabanda]

1. Zapoznanie się z istniejącą koncepcją architektury.
2. Opis na czym polega taki algorytm.
3. Wybór algorytmu elekcji (w naszym przypadku jest to algorytm 'Tyrana'), dlaczego akurat ten?
4. Opis pod implementacjie (ile czasu to zajmie, czy mamy wszystko aby zacząć kodzić, co nas blokuję i co jest potrzebne by to rozwiązać)

Termin: ostateczny 15.05 im wcześniej tym lepiej.

[Gonz8]

Z dokumentacji:

Jeden z serwerów jest koordynatorem. Koordynator kontroluje pracę pozostałych serwerów, sprawdza, czy wszystkie są dostępne, autoryzuje nowy węzeł, który chce się połączyć. Tworzy i rozsyła do wszystkich węzłów tablicę aktywności serwerów. Sprawdzanie obecności serwerów odbywa się poprzez cykliczne odpytywanie. Okres odpytywania jest zawarty w pliku konfiguracyjnym. Gdy master ulegnie awarii jego rolę przejmuje inny z serwerów. W projekcie zastosowano algorytm Tyrana. Algorytm elekcji: Wszystkie serwery znają liczbę i adresy pozostałych. Każdy z serwerów ma przyporządkowany numer. Masterem staje się ten o najniższym numerze. Pierwszy serwer, który zauważy, że nie ma mastera wysyła komunikat ELECTION do wszystkich węzłów o niższym numerze, jeżeli nikt nie odpowie to serwer staje się nowym koordynatorem i wysyła do wszystkich pozostałych węzłów informujący komunikat COORDINATOR. Jeżeli któryś z węzłów o niższym numerze odpowie to on przejmuje kontrolę. Brak koordynatora będzie zauważony, gdy węzeł nie zostanie odpytany w odpowiednim czasie.

Algorytm elekcji będzie realizowany zarówno w warstwie wewnętrznej jak i zewnętrznej. Problemem może być moment rozpoczęcia algorytmu elekcji (ostatnie zdanie). Z Magdą już rozmawiałem na ten temat i pewnie zrobimy tak, że po zauważeniu brak koordynatora, serwer czeka losowy czas i dopiero wysyła komunikat 'elekcja' W pierwotnym założeniu dla wszystkich węzłów czas odpytywania jest jednakowy i może wystąpić przypadek, że wszystkie serwery zauważą brak mastera i wszystkie rozpoczną elekcję co chyba jest niepotrzebne.

Ad.4 Ciężko stwierdzić ile czasu to zajmie, na razie nie mamy komunikacji między serwerami więc nie mogą się one ze sobą komunikować i to właśnie komunikacja powinna być dla nas priorytetem bo na tym wszystko będzie bazować, Można zastosować zaślepki na wejścia, wyjścia i zakodzić sam mechanizm elekcji.

Dajcie znać jak robimy z tą komunikacją, na kiedy planujemy ją zaimplementować? Wg terminów na kiedy mój algorytm powinien być gotowy?

[Gonz8]

Elekcja gotowa :dancer: Działa na następujących zasadach:

1. Jeśli serwer zauważy brak mastera (nie został odpytany we właściwym czasie) to rozpoczyna elekcję czyli pobiera listę wszystkich serwerów "pod nim" i wysyła wiadomość ELECTION oraz ustawia flagę isMasterCandidate (dodatkowo jeśli powyższa lista jest pusta lub lista aktywnych serwerów równa 1 to od razu ustawia siebie jako Mastera :D )
2. Serwer po otrzymaniu ramki ELECTION przejmuje elekcję (ustawia flagę itp) i wysyła wiadomość _ELECTIONSTOP do sendera, a ten zeruje swoją flagę i zaprzestaje uczestnictwa w elekcj po otrzymaniu wiadomości stopu
3. Bazujemy jednak na nieudanej próbie wysłania ramki ELECTION przez kandydata na mastera zamiast cyklicznego sprawdzania nadejścia ramki stopu lub nie :o I właśnie przy nieudanej próbie wysłania wiadomości przez kandydata zwiększamy licznik nieudanych prób wysłania tejże wiadomości Jeśli nie jest on równy liczbie serwerów "pod" zakładamy że ktoś nam odpowie, w przeciwnym wypadku mianujemy się masterem i wysyłamy wiadomość COORDINATOR
4. Serwer po odebraniu wiadomości COORDINATOR ustawia nowego mastera i mamy FINITO!!!

[Gonz8]

aha jeszcze jedno Przeniesienie tego do serwera danych

Proponuję, aby wykonać to po najnowszym pushu dotyczącym tego modułu lub po wspólnym przetestowaniu działania całości we wtorek

@mead15, @magdamagda jak myślicie? Dużo czasu mi to nie zajmie, a bd pewność że działa :dancers: