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

68 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
mentowano częściowo algorytm SC-ABC. OceanStore zbudowane jest używając
Tapestry - warstwy komunikacyjnej peer-to-peer, która zdaje się mieć słabszą
wydajność w przekazywaniu komunikatów niż Pastry, jednak gwarantuje większą
niezawodność [LKRG03, ZHS + 03, RD01b]. Projektowany system będzie
realizował następujące, podstawowe operacje:
insert (id, creds, object) - wprowadza obiekt identyfikowany przez globalnie
unikalny identyfikator id do systemu wraz z uprawnieniami creds 6 .
lookup (id, creds, object*) - zwraca obiekt zidentyfikowany przez id weryfikując
operację przy użyciu uprawnień creds.
invoke (id, creds, operation, params, results*) - wywołuje operację na
obiekcie identyfikowanym przez id pod warunkiem poprawnej weryfikacji
uprawnień creds. Wynik operacji zwracany jest w zmiennej results.
remove (id, creds) - usuwa obiekt z systemu o identyfikatorze id pod
warunkiem poprawnej identyfikacji uprawnień creds.
Podział na wyżej wymienione metody wynika z ich różnorakiej obsługi przez
grupę replikującą. Operacja insert rozpoczyna działanie protokołu na rzecz
konkretnego obiektu. Usługa powinna stać się dostępna, gdy będzie wiadomo,
że obiekt został umieszczony w przynajmniej 2f +1 replikach. Na rysunku
4.3 pokazano różne możliwe typy zachowania klienta i grupy replik podczas
wprowadzania obiektu. W pierwszym przypadku (a) klient stara się wprowadzić
obiekt do systemu, jednak replika, do której wysłał zlecenie jest nieuczciwa i nie
wypycha kopii obiektu do innych replik; (b) klient rozsyła wiadomość do kilku
replik i czeka na odpowiedzi; (c) klient ponownie wysyła komunikat do jednej
z replik i czeka na odpowiedź od różnych replik, gdy otrzymają one obiekt.
Gdy obiekt zostanie poprawnie umieszczony w systemie, to grupa replik
może zacząć przetwarzanie napływających zleceń. Rozpatrując operację lookup,
łatwo można zauważyć, że nie modyfikuje ona stanu obiektu i może zostać obsłużona
nawet przez jedną replikę, jednak wymaga również rozpatrzenia kilku
przypadków, gdyż klient może np. wymagać potwierdzenia stanu odebranego
obiektu od większości replik w grupie. Wywołanie invoke jest operacją modyfikującą
stan obiektu, dlatego konieczne jest ustalenie kolejności realizacji zleceń
przez repliki i zatwierdzenie stanu końcowego. Tu niezbędnym jest wprowadzenie
protokołu uzgadniającego stan. Zakończenie działania protokołu na rzecz
obiektu zachodzi, gdy zostanie odebrane zlecenie remove. Usunięcie obiektu
6 Mechanizm zarządzania i weryfikacji uprawnień został naszkicowany w następnym rozdziale,
który dotyczy projektu systemu Pastor. Na chwilę obecną wystarczy założyć, że uprawnienia
jednoznacznie określają, kto i jakie operacje może wykonać.