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