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.

24 Rozdział 2. Architektury systemów <strong>peer</strong>-<strong>to</strong>-<strong>peer</strong><br />

uprzednio opisany przy czym k 2 staje się, którymś krańcem istniejącego<br />

już przedziału. Dalsze podziały niekoniecznie dzielą obszar <strong>na</strong> dwie równe<br />

części.<br />

4. W miarę coraz większej liczby <strong>na</strong>pływających węzłów liczba przedziałów<br />

będzie rosła. Należy zatem ograniczyć <strong>na</strong>jmniejszą możliwą długość przedziału<br />

do stałej war<strong>to</strong>ści, zależnej od N. Gdy węzeł przybędzie do sieci,<br />

ajegoid przypadnie <strong>na</strong> przedział, którego nie da się podzielić, <strong>to</strong> nie<br />

otrzyma on, żadnej przestrzeni pod swoją jurysdykcję z wyjątkiem obiektów<br />

o identyfika<strong>to</strong>rze równym id. Węzeł będzie mógł przejąć przedział,<br />

gdy węzeł, który się nim opiekuje odłączy się od sieci. Ten węzeł przejmie<br />

przedział, którego id będzie <strong>na</strong>jbliższe do id byłego właściciela.<br />

5. Rozpatrzmy przypadek, gdy węzeł u odłączy się od systemu. Wtedy węzeł<br />

v przejmie pod swoją jurysdykcję obszar, który był przypisany u. Oczywiście<br />

ważne jest, by v zdawał sobie sprawę z istnienia węzła m, który<br />

otrzymał pod swoją jurysdykcję inny obszar. Nakłada <strong>to</strong> wymóg, żeby<br />

węzeł, który dzieli swój zbiór identyfika<strong>to</strong>rów przydzielając go przybywającemu<br />

węzłowi informował o tej operacji węzeł, od którego otrzymał<br />

obszar uprzednio.<br />

Opisany powyżej system jest ustrukturalizowanym systemem <strong>peer</strong>-<strong>to</strong>-<strong>peer</strong>,<br />

gdy dodatkowo zas<strong>to</strong>suje się dla niego odpowiedni algorytm routingu, uwzględniający<br />

jakie węzły mają być utrzymywane w tablicy tras. Przykład nie pochodzi<br />

z literatury i został opracowany <strong>na</strong> potrzeby tej pracy, chociaż przypomi<strong>na</strong> on<br />

CAN z parametrem d =2.<br />

2.2.2 Trasowanie przedrostkowe<br />

Esencją up2p jest zas<strong>to</strong>sowanie w ich konstrukcji algorytmu trasowania Plax<strong>to</strong><strong>na</strong><br />

[PRR97] do <strong>na</strong>wigacji w przestrzeni identyfika<strong>to</strong>rów. Działanie algorytmu jest<br />

bardzo proste. Bity identyfika<strong>to</strong>ra węzła dzielone są <strong>na</strong> słowa o długości b. Gdy<br />

węzeł odbierze komunikat, <strong>to</strong> sprawdza z<strong>na</strong>ne mu adresy węzłów i szuka takiego<br />

węzła, którego identyfika<strong>to</strong>r jest <strong>na</strong>jbardziej zgodny w sensie przedrostka<br />

z identyfika<strong>to</strong>rem odbiorcy. Jeżeli okazałoby się, że takich identyfika<strong>to</strong>rów jest<br />

kilka, <strong>to</strong> wybierany jest ten, który jest <strong>na</strong>jbliżej adresu docelowego. Musi być<br />

spełniony jeszcze jeden warunek, by algorytm przekazywał komunikaty zawsze<br />

w kierunku celu, a mianowicie tylko taka długość przedrostka jest dopuszczal<strong>na</strong>,<br />

która jest większa od długości zgodnego przedrostka węzła odbierającego komunikat.<br />

Czyli po odebraniu komunikatu węzeł <strong>na</strong>jpierw ustala jak bardzo jego<br />

identyfika<strong>to</strong>r zgodny jest przedrostkiem z identyfika<strong>to</strong>rem celu. Koniec wę-

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

Saved successfully!

Ooh no, something went wrong!