OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...

More documents

Recommendations

Info

78 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń Incydenty. Incydentem nazywamy sytuację, gdy podczas wykonywania protokołu warunek na liczbę takich samych odpowiedzi od różnych nadawców nie jest spełniony. Tak, jak w prawdziwym świecie reakcja na incydent powinna być przemyślana. Najpierw należy przeanalizować dostępne informacje, następnie wyciągnąć z nich wnioski i podjąć odpowiednią decyzję. Działanie trzeba podjąć natychmiast, gdyż często jedynie szybka reakcja potrafi przywrócić właściwy stan. Incydenty w opisanym protokole mogą pojawiać się w następujących przypadkach: A. Uzgadnianie stanu po wykonaniu zlecenia. B. Uzgadnianie składu grupy replik. C. Transfer stanu między replikami. Dodatkowo każdy incydent może mieć następujący charakter: 1. Przypadkowy. Nadesłane odpowiedzi mają losowe wartości. 2. Odmowy. Nadesłanych odpowiedzi jest za mało, by zagwarantować poprawne działanie. 3. „Koordynowanego buntu”. Nadesłane odpowiedzi dają się podzielić na kilka grup. Niestety żadna nie tworzy wymaganej większości. Iloczyn kartezjański charakteru incydentu i przypadku występowania prowadzi do pełnej listy incydentów (patrz tablica 4.1) oraz możliwych reakcji. 4.5 Zatwierdzanie stanu Opisywana technika transferu stanu wymaga istnienia mechanizmu, który zatwierdzałby stan usługi, jako stabilny. De facto można w tym miejscu posłużyć się techniką zatwierdzania stanu (ang. checkpointing) opisaną w poprzednim rozdziale, użytą w algorytmie BFT. Pozostaje do rozpatrzenia, czy rzeczywiście zatwierdzanie stanu musi odbywać się w sposób bezpośrednio koordynowany oraz czy wymaga zebrania „dowodu stabilności”. Poprzez bezpośrednią koordynację należy rozumieć technikę, która wymaga komunikacji grupowej oraz doprowadzi do wspólnego zatwierdzenia stanu. Na rysunku 4.7 pokazano, że dowolny moment zatwierdzenia stanu przez replikę może prowadzić do jej awarii. Dlaczego? Przecież można transferować stan od repliki o numerze trzecim, oraz wszystkie zlecenia, tak, że replika
4.5 Zatwierdzanie stanu 79 0 1 2 3 s 3 s 0 s 1 s 2 {s 0 , s 1 ,s 2 ,s 3 } Rysunek 4.7: Przebieg z lokalnym zapamiętywaniem stanu przez repliki. Po ponownym podłączeniu czwarta replika nie jest w stanie odzyskać sprawności. czwarta będzie odświeżona? Niestety nie można tak postąpić z powodu braku zaufania, do którejkolwiek z replik. Oczywiście replika, która uległa awarii ufa samej sobie, dlatego stan s 3 , którym replika dysponuje jest akceptowalny przez nią samą, jednakże nawet po odczytaniu stanu s 3 nadal będą niedostępne zlecenia, które przeprowadzą s 3 do aktualnie obowiązującego stanu. Brakujące zlecenia mogłyby być pobrane od repliki o numerze zero, jednak sytuacja przedstawiona na rys. 4.7 jest tylko specyficznym przypadkiem. Mogłoby się zdarzyć, że ostatni zatwierdzony stan przez replikę odbył się w czasie, gdy replika trzecia uległa awarii, wtedy zleceń nie udałoby się odzyskać. W protokole BFT pokazano, że zatwierdzanie stanu musi odbywać się w sposób koordynowany. Częstość zatwierdzania powinna być dopasowana do obciążenia. Zatwierdzenie stanu powinno odbywać się tak często, jak jest to możliwe, jednak, nie na tyle często, by w znacznym stopniu obciążać usługę. Z drugiej strony zatwierdzenie stanu nie może być za rzadkie, gdyż może to doprowadzić do załamania usługi w przypadku awarii. Generalnie problem częstości wykonywania migawek należałoby rozwiązać budując odpowiednie prawo sterowania, co mogłoby stanowić osobne opracowanie i w tej pracy zostało tylko zasygnalizowane. Sterowanie czasem zapisu migawki. Przez pojęcie stanu usługi będziemy rozumieli stabilną migawkę 13 obiektu oraz wszystkie zlecenia, które jeszcze nie zostały wykonane. Nie uwzględniamy komunikatów, które znajdują się w kanałach komunikacyjnych i nie zostały potwierdzone przez większość replik. Możliwe są dwa podejścia wynikające z założenia, jak uwzględniamy czas potrzebny do wykonania zapisu stanu: 1. Czas odzyskania stanu usługi jest mały w porównaniu do czasu wykonania zleceń - migawki warto wykonywać, jak najczęściej. 13 Czyli obiekt nie będący podczas tranzycji stanu wewnętrznego (wykonania).
Page 1:
Politechnika Warszawska Wydział El
Page 4 and 5:
4 SPIS TREŚCI 3.4 Algorytm SC-ABC
Page 6 and 7:
6 Rozdział 1. Wprowadzenie tyjskic
Page 8 and 9:
8 Rozdział 1. Wprowadzenie • Bez
Page 10 and 11:
10 Rozdział 1. Wprowadzenie torren
Page 12 and 13:
12 Rozdział 1. Wprowadzenie Zalety
Page 14 and 15:
14 Rozdział 1. Wprowadzenie Proxy
Page 17 and 18:
Rozdział 2 Architektury systemów
Page 19 and 20:
19 Overlay level A B C TCP TCP TCP
Page 21 and 22:
2.2 Ustrukturalizowane systemy peer
Page 23 and 24:
Page 25 and 26:
Page 27 and 28: 2.3 Architektura systemów Chord i
Page 29 and 30: 2.3 Architektura systemów Chord i
Page 31 and 32: 2.4 Bezpieczeństwo w systemach pee
Page 33 and 34: 2.4 Bezpieczeństwo w systemach pee
Page 35 and 36: Rozdział 3 Bezpieczne bizantyjskie
Page 37 and 38: 3.1 Problem bizantyjskich generał
Page 39 and 40: 3.2 Replikacja z uwzględnieniem b
Page 41 and 42: 3.3 Algorytm BFT 41 C 0 1 2 pre-pre
Page 43 and 44: 3.3 Algorytm BFT 43 2. Replika gł
Page 45 and 46: 3.3 Algorytm BFT 45 3.3.4 Proaktywn
Page 47 and 48: 3.4 Algorytm SC-ABC 47 pracy nie za
Page 49 and 50: 3.4 Algorytm SC-ABC 49 Rysunek 3.3:
Page 51 and 52: 3.4 Algorytm SC-ABC 51 Secure Causa
Page 53 and 54: 3.4 Algorytm SC-ABC 53 będzie pode
Page 55 and 56: 3.5 Podsumowanie 55 3.5 Podsumowani
Page 57 and 58: 3.5 Podsumowanie 57 Protokół 3.5.
Page 59: 3.5 Podsumowanie 59 Protokół 3.5.
Page 62 and 63: 62 Rozdział 4. Tolerowanie bizanty
Page 85 and 86: Rozdział 5 Projekt systemu Pastor
Page 87 and 88: 5.1 Projekt systemu 87 wykonaniem k
Page 89 and 90: 5.1 Projekt systemu 89 5.1.3 Postar
Page 91 and 92: 5.1 Projekt systemu 91 4 MyPastCont
Page 93 and 94: 5.1 Projekt systemu 93 wydajność,
Page 95: 5.2 Podsumowanie 95 wchodzą w skł
Page 98 and 99: 98 Dodatek A. Elementy teorii graf
Page 104 and 105: 104 Dodatek B. Uzgadnianie w asynch
Page 106 and 107: 106 Dodatek B. Uzgadnianie w asynch
Page 109 and 110: Bibliografia [ADS02] [CC] J. Aspnes
Page 111 and 112: BIBLIOGRAFIA 111 [DZDS03] [FLP85] [
Page 113: BIBLIOGRAFIA 113 [Sho00] Victor Sho
show all

OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...