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

More documents

Recommendations

Info

64 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń • Żywotność (ang. liveness) - zlecone operacje zostaną wykonane w skończonym czasie t
4.2 Założenia projektowe 65 • Poczta elektroniczna (wielu piszących, jeden czytający). Obiektem jest skrzynka pocztowa. Wystarczy, że dostęp do skrzynki będzie realizowany z zachowaniem rozłączności operacji wykonywanych przez różnych klientów (operacje nie przeplatają się). Nie istnieje operacja modyfikacji uprzednio wysłanych wiadomości. • Usługa nazewnicza (jeden piszący, wielu czytających). Obiektem jest pojedynczy rekord < nazwa, adres >. W tym przypadku, występuje tylko jeden piszący i w zasadzie nie trzeba się zbytnio przejmować spójnością danych, za wyjątkiem takich zastosowań, które wymagają bezwzględnej poprawności i świeżości odczytywanych danych. • Komunikacja natychmiastowa (ang. instant messaging) (jeden piszący, jeden czytający). Obiektem jest komunikacyjny bufor wiadomości. To zastosowanie jest bezpośrednim odzwierciedleniem problemu producentkonsument. W tym przypadku, ważne jest, by operacje odczytu zwracały wiadomości zgodnie z ich kolejnością napływania. • Obliczenia i koordynacja rozproszona (wielu piszących, wielu czytających). Obiekt jest elementem obliczeniowym lub semaforem. W tym przypadku kolejność wykonywanych obliczeń ma zasadnicze znaczenie i ważne jest zagwarantowanie przynajmniej deterministycznego zachowania usługi, tzn. ta sama sekwencja operacji zlecona przez wielu klientów zwróci taki sam wynik końcowy przy takim samym stanie początkowym usługi. Przytoczone przykłady rzeczywistych zastosowań usprawiedliwiają realizację słabszego typu spójności niż spójność sekwencyjna, czy nawet liniowa. Wydaje się, że sprostanie warunkom stawianym przez rzeczywiste zastosowania wymaga zapewnienia spójności przyczynowej (ang. causal consistency) 5 , chociaż w systemie peer-to-peer będzie to trudne do zapewnienia. Niezawodne rozgłaszanie. Protokół uzgadniania wymaga użycia niezawodnego rozgłaszana podczas wysyłania komunikatów do członków grupy. Dlaczego? W momencie otrzymania zlecenia od klienta replika powinna rozesłać zlecenie do wszystkich pozostałych replik, a następnie czekać na nadejście odpowiedzi. Gdy nie ma gwarancji na dostarczenie komunikatu do wszystkich działających replik, nadawca nie ma pewności, czy wszystkie poprawnie działające repliki otrzymały komunikat. Może okazać się, że podczas rozgłaszania, któraś z replik się odłączyła, nadawca uległ awarii lub zakończył działanie. Niezawodne rozgłaszanie daje grupie wiedzę na temat jej aktualnego składu, czyli repliki mogą decydować 5 Operacje wpływające na siebie, powinny zachować porządek 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 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 ...