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

More documents

Recommendations

Info

82 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń W tym paragrafie przedstawiłem protokół zatwierdzania stanu pokazując wcześniej, że brak uzgodnienia momentu zapisu mógłby doprowadzić do niepożądanego działania usługi. W uzupełnieniu do protokołu BFT został pokazany prosty sposób sterowania częstością zapisu, który mógłby okazać się zawodny przy większych wymaganiach, jednak stanowi rozwiązanie, które może zostać użyte po małych modyfikacjach w praktycznej realizacji. 4.6 Protokół optymistyczny Twierdzenie o nie istnieniu konsensusu w całkowicie asynchronicznym systemie w obecności choć jednego nieuczciwie działającego procesu Fischera [FLP85] mówi o tym, że próba uzgadniania bez synchronizacji może nie przynieść rezultatu. Jednak nadal istnieje szansa, że uzgadnianie się powiedzie. Protokoły, które dopuszczają możliwość zaistnienia błędnego przebiegu przyjęło się nazywać protokołami optymistycznymi. W przypadku, gdy protokół optymistyczny zawiedzie wykonanie zostaje przełączone w tryb użycia protokołu zachłannego. Opisywane w poprzednim rozdziale protokoły BFT i SC-ABC posiadają swoje wersje optymistyczne. Protokół BF2 można również zmodyfikować w taki sposób, że zostanie wyeliminowana duża część synchronizacji między replikami, a powrót do protokołu właściwego nastąpi podczas wykrycia błędów. • Wykonanie protokołu BF2 w punkcie trzecim zakłada uzgodnienie przez repliki zbudowanego wektora R g . W protokole optymistycznym zamiast uzgadniać R g używając komunikatu request-ready natychmiast przechodzimy do fazy wykonania zleceń. • Faza wykonania zlecenia może również zostać skrócona. W tym przypadku replika zapamiętuje stan obiektu sprzed wykonania zlecenia i wykonuje je natychmiast, następnie rozgłasza komunikat pre-commit. Gdy protokół zawiedzie, replika wycofuje wykonanie zlecenia. • Podążając za tokiem rozumowania z poprzedniego punktu, replika może wysłać odpowiedź do klienta od razu po wykonaniu zlecenia, jeżeli nie modyfikuje ono stanu usługi. Klient w przypadku odebrania za małej liczby takich samych odpowiedzi ponownie wyśle zlecenie ustawiając dodatkową flagę retrospect. Replika po odebraniu takiego zlecenia wie, że uprzednio wykonanie nie powiodło się i należy zrealizować całą operację z uwzględnieniem wszystkich kroków. Przełączenie w tryb wykonania protokołu zachłannego powinno następować zaraz po wykryciu niepoprawnego działania. Powrót do optymistycznego proto-
4.7 Podsumowanie 83 kołu może nastąpić wraz z rozpoczęciem wykonania nowej rudny, jednak dopiero po uzgodnieniu wektora R g . 4.7 Podsumowanie Protokół BF2, zaproponowany w tym rozdziale, jest przeznaczony dla systemów rozproszonych, w których istnieje konieczność tolerowania uszkodzeń bizantyjskich, tzn. takich w których poszczególne elementy mogą zachowywać się w sposób arbitralny, a dynamika zmiany struktury systemu jest bardzo duża. BF2 jest podobny w wielu aspektach do protokołu BFT opisanego w poprzednim rozdziale 14 , jednak różni się znacząco w sposobie synchronizacji i uzgadniania zleceń do wykonania przez repliki. BFT przeznaczony jest raczej dla systemów, które charakteryzują się statyczną strukturą. Podstawowym mechanizmem stosowanym do ustalenia kolejności wykonania w BFT są widoki. W każdym widoku jeden z węzłów uczestniczących jest koordynatorem i do niego muszą być kierowane wszystkie zlecenia. Mechanizm widoków w BF2 został zastąpiony przez technikę wykonania zleceń w rundach, co jest usprawiedliwione przy dużej dynamice grupy replik. Wyznaczanie koordynatora użyte w BFT zakłada, że repliki są ponumerowane w ten sposób, że możliwe jest jednoznaczne ustalenie kolejnej repliki głównej, natomiast w BF2 nie jest to wymagane. W tym rozdziale przedstawiono techniki konstrukcji grupy replik oraz protokoły realizujące przyłączanie i odłączanie węzłów, czego nie specyfikuje ani BFT ani SC-ABC. Projekt protokołu został poszerzony o opis problemu zatwierdzania stanu, gdzie sformułowano problem sterowania częstością zatwierdzania migawki i podano sprawne, choć może nie optymalne rozwiązanie. Podobnie jak w BFT oraz SC-ABC, w BF2 można zastosować wersję optymistyczną protokołu, co w praktycznej realizacji powinno zwiększyć wydajność systemu, wtedy gdy środowisko pracy nie jest ekstremalnie nieprzychylne. Kolejny rozdział opisuje projekt systemu Pastor, który implementuje algorytm BF2 w jego podstawowej postaci. 14 Dlatego przyjęto oznaczenie BF2.
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 ...

Create successful ePaper yourself

Delete template?

Save as template?

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