Odporność na błędy (fault tolerance)¶
Są 2 rodzaje błędów sieci: złośliwe i łagodne (ang. benign)
- łagodne – wierz lub kraw przestaje działać „na zawsze” (np. "crash" procesorów)
- złośliwe - wierz lub kraw(?) zachowuje się w sposób nieprzewidywalny
Problemy które rozważymy:
- problem 2 generałów (atakujących miasto z przeciwnych stron)
- consensus (wszyscy muszą się zgodzić na tą samą liczbę)
problem 2 generałów (coordinated attack problem) - form. def.¶
chodzi o podjęcię wspólnej decyzji o ataku...
psują się połączenia (komunikaty nie są dostarczane)
– chęć , – ostateczna decyzja
formalnie: mamy 2 procesory i ; mają być spełnione warunki:
- „agreement”, , czyli wspólna decyzja...
- „validity”, if , żaden kom. nie został dost., to
- „nontriviality”, istnieje egzekucja, w której
consensus - form. def.¶
każdy procesor ma liczbę na wejściu,
chodzi o wybranie wspólnej liczby spośród ,
przez te proc które się nie popsuły („crash” procesorów)
formalnie: mamy procesory P1, .., Pn; mają być spełnione warunki:
- „agreement”, dla wsz niepopsutych Pi, Pj
- „validity”, in {, ..., }, dla wsz niepopsutych Pi
problem 2 generałów¶
przypomnieć pojęcie egzekucji asynch (konfiguracja początkowa i ciag zdarzeń) ...
Tw: nie istnieje alg rozwiązujący problem 2 generałów
Dowód:
def: a|P = egzekucja „a” z pkt widzenia procesora P
def: /P/ = egz i są nierozróżnialne z pkt widzenia P
Zakładamy, że alg istnieje, czyli istnieje egz , w której
dostarcza się „k” komunikatów oraz (z nontriviality).
Konstruujemy egzekucje , która wygląda tak:
Zauważmy, że:
/P1/ oraz w dostarcza się kom, (?)
Następnie tworzymy egz z analogicznie (jak z )
czyli w dostarcza się kom,
…
w dostarcza się 0 kom, ,
czy to już sprzeczność z validity ?
NIE, no nie wiemy czy w 1 konfiguracji było ?!?!
Konstruujemy egz = " z tą zmianą, że "
/P2/ => w egz : (P2 nie widzi innej wart )
Konstruujemy egz = " z tą zmianą, że "
/P1/ => w egz : (P1 nie widzi innej wart )
tzn. jest egz w której , , dostarcza się 0 kom...
SPRZECZNOŚĆ z validity !!!
consensus¶
algorytm "obliczający" consensus:
oraz główne Twierdzenie:
pierwszy proces ma x na WE...
„iteracje”: w której dany proces dostaje x, oraz go wysyła w następnej iteracji (ew. crash) !
Są 2 możliwości:
- przedostatni proces się psuje – sprzeczność (co do f) !!!
- -''- się NIE psuje – wysyła x do Pj
Intuicja algorytmu consensus: wysyłam cenna informację gdzie się da, może przetrwa...
...
Zadania¶
ZADANIE 50 impl algorytmu consensus
Zaprojektuj eksperyment pokazujący nietrywialne działanie algorytmu Consensus...
Nasz symulator nie jest przystosowany do algorytmow synch "psujących się w połowie rundy",
dlatego najlepiej użyc proc blad {iter1 iter2} generującej błąd fibera przy pomocy error "crash",
w odpowiednio dobranej chwili (patrz tutaj),
Uwaga: przez "nietrywialne działanie" rozumiemy takie, w którym coś się zmienia
także w ostatnich iteracjach pętli for...