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

More documents

Recommendations

Info

88 Rozdział 5. Projekt systemu Pastor obiektu, dlatego też wszystkie zabezpieczenia musiałyby być zrealizowane na poziomie wątku wykonania, co dodatkowo rzutuje na wydajność. Wymagania zapewnienia bezpieczeństwa można rozwiązać używając dwóch podejść: • Weryfikacja typu off-line, tzn. architektura aplikacji powinna wykorzystywać mechanizm wtyczek (ang. plug-in), które dostarczane są z wiadomego źródła, jako zewnętrzne klasy. Uruchamiane klasy powinny być podpisane, a ich uprawnienia zależne od polityki bezpieczeństwa. Niestety to podejście ogranicza możliwość przechowania, niektórych obiektów przez węzeł, gdyż mogą one nie mieć wbudowanej odpowiedniej wtyczki. Wytłumaczenie powyższej sytuacji wymaga posłużenia się przykładem: Węzeł u chce umieścić w sieci obiekt klasy A o identyfikatorze A id . Wykonuje operację insert, która przesyła obiekt poprzez sieć do celu, którego identyfikator jest najbliższy względem A id . Przyjmijmy, że punktem docelowym będzie węzeł v. Jeżeli v posiada wtyczkę zawierającą plik A.class, toużywając deserializacji poprawnie odbierze obiekt A i umieści go w swojej pamięci trwałej. W przeciwnym razie próba rozpakowania obiektu A nie powiedzie się i zostanie zgłoszony wyjątek. • Weryfikacja on-line zakłada, że definicje klas są pobierane w sposób dynamiczny i uruchomienie obiektów odbywa się w przygotowanym i nadzorowanym środowisku (np. piaskownicy). To podejście jest znacznie trudniejsze do zaimplementowania, ale nie nakłada ograniczeń co do możliwości przechowywania konkretnych obiektów przez określony węzeł. Wrócę do poprzedniego przykładu. Węzeł u nadal chce przesłać obiekt A do węzła u. W tym celu u opakowuje A oraz zawartość pliku A.class w jeden obiekt Content, którego klasa znana jest obu węzłom. Ponadto obiekt Content implementuje dwie metody put oraz get, które pozwalają „upakować” przesyłane obiekty w standardowych tablicach bajtów. Gdy Content dotrze do v ten rozpakuje najpierw plik A.class i wczyta go używając własnego SecureClassLoader’a, który ustawi ograniczenia dla tego obiektu. W początkowej implementacji systemu Pastor zostały użyte elementy weryfikacji off-line oraz on-line. Obiekty w obecnej implementacji Pastora wysyłane są w specjalnym kontenerze Content, ale bez dołączonej definicji klasy. Definicje pobierane są z wtyczek, które muszą zostać umieszczone w katalogu plugin/ w pliku jar. Więcej informacji na temat bezpieczeństwa w Java 2 czytelnik znajdzie w książce Li Gonga [Gon99].
5.1 Projekt systemu 89 5.1.3 Postarzanie obiektów Użyteczną techniką stosowaną przez DHT zaimplementowanym w systemie Kademlia jest postarzanie obiektów [MM02]. Wcześniej ta technika była stosowana na przykład w systemie plików rozproszonego systemu operacyjnego Amoeba [Tan95], aczkolwiek użycie tej techniki w systemie Amoeba miało zupełnie inne przesłanki, niż ma to miejsce w Kademlii. W Amoebie postarzanie wiązało się z usuwaniem nieużywanych już plików, do których nie odnosi się żadna ścieżka dojścia 1 , starsze pliki, niż pewna ustalona wartość były kasowane. Kademlia implementuje podobny mechanizm. Użytkownik chcąc, by jego obiekt pozostał w DHT Kademlii musi wywołać przynajmniej raz na dobę operację odświeżania, co odpowiada operacji dotknięcia (ang. touch) stosowanej w systemie Amoeba. Przesłanki, jakie kierowały projektantami Kademlii wiązały się z rozsądnym gospodarowaniem przestrzenią dyskową, chociaż przyjęty czas przeterminowania obiektu, czyli doba, wydaje się być trudny do interpretacji. W systemie Pastor, postarzanie obiektów można usprawiedliwić nie tylko optymalizacją zajętości przestrzeni dyskowej, ale też wydatkami komunikacyjnymi na utrzymywanie stanu replik dla obiektów, które nie są więcej wywoływane. FreePastry posiada rozszerzenie GCPast (ang. Garbage Collector Past), które implementuje usuwanie obiektów dlatego Pastor opierał się na tym rozszerzeniu. Implementacja FreePastry Do realizacji oprogramowania użyto wersji FreePastry 1.4.1 (maj 2005), w skład której wchodzą następujące komponenty: • Pastry - substrat peer-to-peer. • Past - implementacja DHT. • Scribe - mechanizm komunikacji grupowej. • Glacier - współdzielenie zawartości (podobne do protokołu BitTorrent). • SplitStream - strumieniowe przesyłanie danych. Jest to duża baza, która pozwala na skonstruowanie nawet bardzo wyszukanych aplikacji rozproszonych. W tym rozdziale nie będę dokładnie opisywał interfejsu programistycznego dostarczanego przez FreePastry, gdyż przedstawienie funkcjonalności tego oprogramowania wykracza daleko poza ramy tej pracy 1 Serwer pików periodycznie odświeżał znaczniki czasu do plików, do których istniały dojścia w systemie katalogowym.
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: 5.1 Projekt systemu 87 wykonaniem k
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 ...