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 ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
3.3 Algorytm BFT 45<br />
3.3.4 Proaktywne odzyskiwanie stanu w BFT<br />
Replika zapisuje do dziennika wszytkie operacje, które wykonuje. Zbiór potwierdzonych<br />
i wyko<strong>na</strong>nych zleceń stanowi o stanie usługi s. Stan s określany<br />
jest jako stabilny, jeżeli jest zatwierdzony. Replika chcąc zatwierdzić stan dla<br />
jakiegoś numeru sekwencji n wysyła komunikat postaci < CHECKPOINT, n,<br />
D(s), i> σi . Zatwierdzenie stanu powinno być przeprowadzane co pewną liczbę<br />
zleceń, w zależności od średniego obciążenia usługi, tak by nie występowało ono<br />
za częs<strong>to</strong>, ale też nie było za rzadkie, gdyż <strong>to</strong> może z<strong>na</strong>cznie wydłużyć operację<br />
zmiany widoku opisaną wcześniej. Jeżeli replika odbierze 2f +1 potwierdzeń, <strong>to</strong><br />
może zatwierdzić stan. Wszystkie wiadomości otrzymane dla niższych numerów<br />
sekwencji od n mogą zostać usunięte z dziennika repliki i.<br />
Proaktywne odzyskiwanie stanu jest procesem, który odświeża stan repliki.<br />
Twórcy algorytmu zakładają, że wszystkie repliki są uruchamiane i <strong>na</strong>dzorowane<br />
przez administra<strong>to</strong>ra systemu. Nie jest bra<strong>na</strong> pod uwagę sytuacja, gdy<br />
replika została uruchomio<strong>na</strong> przez atakującego. Jest <strong>to</strong> poprawne założenie dla<br />
tego przypadku, gdyż jedynie repliki <strong>na</strong>dzorowane mogą rozpocząć proces odzyskiwania<br />
stanu. Ta technika pozwala przywrócić uszkodzoną replikę, która<br />
zachowuje się w sposób bizantyjski, do poprawnego działania. Niestety trudno<br />
jest określić, czy replika działa poprawnie, czy też nie. W związku z powyższym<br />
każda z replik posiada proces <strong>na</strong>dzorujący (ang. watchdog), który co ustalony<br />
interwał rozpoczy<strong>na</strong> kontrolowany restart repliki.<br />
Pro<strong>to</strong>kół estymujący. Faza estymacji ma <strong>na</strong> celu ustalenie, który ostatni numer<br />
sekwencji zleceń repliki uz<strong>na</strong>ją za stabilny. Replika i rozgłasza komunikat <<br />
QUERY-STABLE, i, k> σi , gdzie k jest losową liczbą. Kiedy replika j odbierze<br />
komunikat wysyła odpowiedź < REPLY-STABLE, c, e, i, k> σj i, c jest ostatnim<br />
stabilnym numerem sekwencji, e jest ostatnim numerem sekwencji zlecenia<br />
przygo<strong>to</strong>wanym przez j. Replika i zachowuje <strong>na</strong>jmniejszą war<strong>to</strong>ść c oraz <strong>na</strong>jwiększą<br />
e oraz swoje własne. Następnie szacuje H M = L + c M , gdzie L jest<br />
rozmiarem dziennika, <strong>na</strong><strong>to</strong>miast c M musi być większe od jakiegokolwiek ostatniego<br />
z<strong>na</strong>cznika zatwierdzenia, c M jest taką war<strong>to</strong>ścią otrzymaną od repliki j,<br />
że przy<strong>na</strong>jmniej 2f replik podało c mniejsze bądź równe od c podanego przez<br />
j oraz f replik różnych od j podało war<strong>to</strong>ści e większe bądź równe c M .<br />
Zlecenie odzyskania stanu. Replika i wysyła zlecenie odzyskania stanu <<br />
REQUEST, < RECOVERY, H M >, t, i > σi . Parametr t w wywołaniu musi być<br />
losowym z<strong>na</strong>cznikiem większym od uprzednio wysłanego. Replika j odrzuci<br />
wiadomość z t mniejszym od uprzedniego, jak również taką wiadomość, która<br />
była <strong>na</strong>da<strong>na</strong> przez i w czasie nie większym niż połowa okresu odnowienia repliki.<br />
Takie postępowanie ma <strong>na</strong> celu wykluczenie ataków zablokowania usługi typu<br />
DoS (ang. denial-of-service), który byłby wynikiem całkowitego obciążenia
Change language