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

4.3 Zestaw dostępnych operacji 67
r 1
1
Prepare{r 11 }
Commit{r 11 }
0
1
2
3
r 2
1
R g
{r 1 1 , r 12 }
R g { r 12 }
Vote-request
Pre-commit{r
11 }
Rysunek 4.2: Szkic działania protokołu dla grupy czterech replik i nadesłania
zleceń przez dwóch klientów.
twierdzenia wykonania i musi zostać potwierdzony przez co najmniej f +1
replik. Opisana procedura odpowiada protokołowi trójfazowego zatwierdzania
[TS01].
W przypadku, gdy replika j wysłała już komunikat vote-response z podanym
wektorem R j , wstawia wszystkie napływające zlecenia do swojej kolejki
i po zakończeniu bieżącej rundy sama może zainicjować nowe wykonanie wysyłając
vote-request. Mechanizm rund wprowadza do protokołu pewien stopień
synchroniczności, gdyż repliki muszą uzgodnić wykonanie zanim przejdą do
fazy realizacji zleceń. Tutaj należy mieć na uwadze twierdzenie wprowadzone
w rozdziale trzecim, które neguje istnienie protokołu, który byłby całkowicie
asynchroniczny i pozwalał grupie replik dojść do konsensusu w obecności błędów.
4.3 Zestaw dostępnych operacji
Protokół bizantyjskiego uzgadniania pozwala na replikację usługi, dlatego można
w oparciu o ten protokół zrealizować więcej operacji, niż tylko put,get,delete,
które tworzą ogólny interfejs DHT [DZDS03], ale również zaproponowaną w
BFT operację invoke. Nazewnictwo metod pozostanie zgodne z obowiązującym
wsystemiePast [RD01a], który implementuje rozproszoną tablicę z kodowaniem
mieszającym dla obiektów, zbudowany na bazie warstwy komunikacyjnej
Pastry. Past nie umożliwia zlecania wykonania operacji na obiektach, jak
również nie jest odporny na bizantyjskie uszkodzenia. Zaprojektowano system
bardzo podobny do Past o nazwie OceanStore opracowany w Berkeley University
of California [KBC + 00], w którego prototypie Pond [REG + 03], zaimple-