10.03.2015 Views

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 ...

SHOW MORE
SHOW LESS

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

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.2 Założenia projek<strong>to</strong>we 65<br />

• Poczta elektronicz<strong>na</strong> (wielu piszących, jeden czytający). Obiektem jest<br />

skrzynka pocz<strong>to</strong>wa. Wystarczy, że dostęp do skrzynki będzie realizowany z<br />

zachowaniem rozłączności operacji wykonywanych przez różnych klientów<br />

(operacje nie przeplatają się). Nie istnieje operacja modyfikacji uprzednio<br />

wysłanych wiadomości.<br />

• Usługa <strong>na</strong>zewnicza (jeden piszący, wielu czytających). Obiektem jest pojedynczy<br />

rekord < <strong>na</strong>zwa, adres >. W tym przypadku, występuje tylko<br />

jeden piszący i w zasadzie nie trzeba się zbytnio przejmować spójnością<br />

danych, za wyjątkiem takich zas<strong>to</strong>sowań, które wymagają bezwzględnej<br />

poprawności i świeżości odczytywanych danych.<br />

• Komunikacja <strong>na</strong>tychmias<strong>to</strong>wa (ang. instant messaging) (jeden piszący,<br />

jeden czytający). Obiektem jest komunikacyjny bufor wiadomości. To<br />

zas<strong>to</strong>sowanie jest bezpośrednim odzwierciedleniem problemu producentkonsument.<br />

W tym przypadku, ważne jest, by operacje odczytu zwracały<br />

wiadomości zgodnie z ich kolejnością <strong>na</strong>pływania.<br />

• Obliczenia i koordy<strong>na</strong>cja rozproszo<strong>na</strong> (wielu piszących, wielu czytających).<br />

Obiekt jest elementem obliczeniowym lub semaforem. W tym<br />

przypadku kolejność wykonywanych obliczeń ma zasadnicze z<strong>na</strong>czenie i<br />

ważne jest zagwaran<strong>to</strong>wanie przy<strong>na</strong>jmniej deterministycznego zachowania<br />

usługi, tzn. ta sama sekwencja operacji zleco<strong>na</strong> przez wielu klientów<br />

zwróci taki sam wynik końcowy przy takim samym stanie początkowym<br />

usługi.<br />

Przy<strong>to</strong>czone przykłady rzeczywistych zas<strong>to</strong>sowań usprawiedliwiają realizację<br />

słabszego typu spójności niż spójność sekwencyj<strong>na</strong>, czy <strong>na</strong>wet liniowa. Wydaje<br />

się, że sprostanie warunkom stawianym przez rzeczywiste zas<strong>to</strong>sowania wymaga<br />

zapewnienia spójności przyczynowej (ang. causal consistency) 5 , chociaż w systemie<br />

<strong>peer</strong>-<strong>to</strong>-<strong>peer</strong> będzie <strong>to</strong> trudne do zapewnienia.<br />

Niezawodne rozgłaszanie. Pro<strong>to</strong>kół uzgadniania wymaga użycia niezawodnego<br />

rozgłasza<strong>na</strong> podczas wysyłania komunikatów do członków grupy. Dlaczego? W<br />

momencie otrzymania zlecenia od klienta replika powin<strong>na</strong> rozesłać zlecenie do<br />

wszystkich pozostałych replik, a <strong>na</strong>stępnie czekać <strong>na</strong> <strong>na</strong>dejście odpowiedzi. Gdy<br />

nie ma gwarancji <strong>na</strong> dostarczenie komunikatu do wszystkich działających replik,<br />

<strong>na</strong>dawca nie ma pewności, czy wszystkie poprawnie działające repliki otrzymały<br />

komunikat. Może okazać się, że podczas rozgłaszania, któraś z replik się odłączyła,<br />

<strong>na</strong>dawca uległ awarii lub zakończył działanie. Niezawodne rozgłaszanie<br />

daje grupie wiedzę <strong>na</strong> temat jej aktualnego składu, czyli repliki mogą decydować<br />

5 Operacje wpływające <strong>na</strong> siebie, powinny zachować porządek wyko<strong>na</strong>nia.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!