10.03.2015 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

4.5 Zatwierdzanie stanu 79<br />

0<br />

1<br />

2<br />

3<br />

s 3<br />

s 0<br />

s 1<br />

s 2<br />

{s 0 , s 1 ,s 2 ,s 3 }<br />

Rysunek 4.7: Przebieg z lokalnym zapamiętywaniem stanu przez repliki. Po<br />

ponownym podłączeniu czwarta replika nie jest w stanie odzyskać sprawności.<br />

czwarta będzie odświeżo<strong>na</strong>? Niestety nie moż<strong>na</strong> tak postąpić z powodu braku<br />

zaufania, do którejkolwiek z replik. Oczywiście replika, która uległa awarii<br />

ufa samej sobie, dlatego stan s 3 , którym replika dysponuje jest akcep<strong>to</strong>walny<br />

przez nią samą, jed<strong>na</strong>kże <strong>na</strong>wet po odczytaniu stanu s 3 <strong>na</strong>dal będą niedostępne<br />

zlecenia, które przeprowadzą s 3 do aktualnie obowiązującego stanu. Brakujące<br />

zlecenia mogłyby być pobrane od repliki o numerze zero, jed<strong>na</strong>k sytuacja przedstawio<strong>na</strong><br />

<strong>na</strong> rys. 4.7 jest tylko specyficznym przypadkiem. Mogłoby się zdarzyć,<br />

że ostatni zatwierdzony stan przez replikę odbył się w czasie, gdy replika trzecia<br />

uległa awarii, wtedy zleceń nie udałoby się odzyskać.<br />

W pro<strong>to</strong>kole BFT pokazano, że zatwierdzanie stanu musi odbywać się w<br />

sposób koordynowany. Częs<strong>to</strong>ść zatwierdzania powin<strong>na</strong> być dopasowa<strong>na</strong> do<br />

obciążenia. Zatwierdzenie stanu powinno odbywać się tak częs<strong>to</strong>, jak jest <strong>to</strong><br />

możliwe, jed<strong>na</strong>k, nie <strong>na</strong> tyle częs<strong>to</strong>, by w z<strong>na</strong>cznym s<strong>to</strong>pniu obciążać usługę.<br />

Z drugiej strony zatwierdzenie stanu nie może być za rzadkie, gdyż może <strong>to</strong><br />

doprowadzić do załamania usługi w przypadku awarii. Generalnie problem częs<strong>to</strong>ści<br />

wykonywania migawek <strong>na</strong>leżałoby rozwiązać budując odpowiednie prawo<br />

sterowania, co mogłoby stanowić osobne opracowanie i w tej pracy zostało tylko<br />

zasyg<strong>na</strong>lizowane.<br />

Sterowanie czasem zapisu migawki. Przez pojęcie stanu usługi będziemy rozumieli<br />

stabilną migawkę 13 obiektu oraz wszystkie zlecenia, które jeszcze nie<br />

zostały wyko<strong>na</strong>ne. Nie uwzględniamy komunikatów, które z<strong>na</strong>jdują się w ka<strong>na</strong>łach<br />

komunikacyjnych i nie zostały potwierdzone przez większość replik.<br />

Możliwe są dwa podejścia wynikające z założenia, jak uwzględniamy czas<br />

potrzebny do wyko<strong>na</strong>nia zapisu stanu:<br />

1. Czas odzyskania stanu usługi jest mały w porów<strong>na</strong>niu do czasu wyko<strong>na</strong>nia<br />

zleceń - migawki war<strong>to</strong> wykonywać, jak <strong>na</strong>jczęściej.<br />

13 Czyli obiekt nie będący podczas tranzycji stanu wewnętrznego (wyko<strong>na</strong>nia).

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!