Odporność na błędy bizantyjskie w systemach peer-to-peer - Instytut ...

66 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
o tym, które zlecenia zostaną wykonane a które nie. Warto zauważyć, że usługa
niezawodnego rozgłaszania nie koniecznie musi gwarantować w tym przypadku
całkowite uporządkowanie komunikatów (ang. totally ordered multicast), czy
właściwość atomowego rozgłaszania (ang. atomic multicast), która zapewnia, że
wiadomość zostanie dostarczona do wszystkich aktywnych uczestników lub do
nikogo. Zapewnienie niezawodnego rozgłaszania jest konieczne, gdyż wszystkie
poprawnie działające repliki muszą dowiedzieć się o tym, które zlecenia zostały
przez nie pominięte i które powinny wykonać, by pozostać w synchronizacji z
innymi replikami.
Ogólny opis działania protokołu. Węzeł po włączeniu się do systemu zostaje
przyłączony do grupy replik, których identyfikatory znajdują się w jego otoczeniu.
Jest on zapraszany do istniejącej grupy replik lub tworzy własną grupę.
W pierwszym przypadku, węzeł pobiera stan i zaczyna uczestniczyć w wykonywaniu
protokołu, natomiast w drugiej sytuacji zaprasza szereg replik do swojej
grupy, do momentu gdy osiągnie ona oczekiwany rozmiar.
Klient c, może wysłać zlecenie r c s do dowolnej repliki i, przy czym zlecenia
muszą być kolejno ponumerowane przez klienta używając odpowiedniego s.
Repliki działają spełniając zlecenia w rundach r g numerowanych kolejno. Runda
składa się z grupy zleceń odebranych przez repliki od momentu rozpoczęcia poprzedniej
rundy do chwili bieżącej. Rundy są mechanizmem, który wprowadza
pewien stopień synchronizacji w protokole, podobnie jak ma to miejsce BFT w
przypadku stosowania techniki widoków.
Zaletą wykonania zleceń w rundach w stosunku do wirtualnej synchroniczności
jest rzadka konieczność interwencji, nawet gdy któraś z replik przestałaby
odpowiadać. W BFT należy przeprowadzić zmianę widoku zawsze gdy zawodzi
replika główna, a wyznaczenie nowej repliki głównej wymaga ponumerowania
replik. Długość rundy może zostać ograniczona, ale wskazane jest, by repliki
dopasowywały długość okna rundy dla wykonania zleceń w zależności od obciążenia,
podobnie jak w sterowaniu częstością zapisu stanu.
Replika otrzymując zlecenie od klienta rozsyła komunikat rozpoczynający
kolejną rundę vote-request i czeka na akceptację od 2f +1 replik uwzględniając
siebie samą, które w odpowiedzi rozgłaszają wektor R j zawierający zlecenia,
które repliki chcą wykonać w danej rundzie. Każda replika składa wszystkie
wektory odpowiednio uwzględniając kolejność wykonania i rozsyła wektor R g
do reszty replik, następnie czeka na 2f +1 takich samych odpowiedzi od różnych
replik uwzględniając siebie samą. Po zebraniu wymaganej liczby komunikatów
replika wybiera pierwsze zlecenie z R g i rozgłasza wiadomość przygotowania
prepare dla tego zlecenia i ponownie czeka na odpowiednią liczbę komunikatów.
W następnej kolejności rozsyła wiadomość pre-commit zawierającą wynik
wykonania zlecenia. Komunikat commit, zostaje wysłany na końcu w celu za-