Come funziona la tabella di routing di Population Pastry?

Sto cercando di implementare la tabella degli hash distribuiti in pasticceria, ma alcune cose stanno sfuggendo alla mia comprensione. Speravo che qualcuno potesse chiarire.

Disclaimer : non sono uno studente di informatica. Ho seguito esattamente due corsi di informatica nella mia vita, e nessuno dei due ha affrontato nulla di remoto. Ho lavorato con il software per anni, quindi mi sento all'altezza del compito di implementazione, se solo potessi avvolgere la testa attorno alle idee. Quindi potrei semplicemente mancare qualcosa di ovvio.

Ho letto il documento pubblicato dagli autori [1] e ho fatto dei buoni progressi, ma continuo a rimanere impiccato su questo punto in particolare su come funziona la tabella di routing:

Il documento afferma che

La tabella di routing di un nodo, , è organizzata in ⌈ log 2 b N ⌉ righe con 2 b - 1 voci ciascuna. Il 2 b - 1 voci alla riga n della tabella di routing ogni riferimento ad un nodo cui azioni NodeID nodeId presente nodo nel primo n cifre, ma il cui n + 1 esima cifra ha uno dei 2 b - 1 valori possibili diversa il n + 1 digit esimo id presente nodo.$R$$\lceil \log_{2^b} N\rceil$$2^b - 1$$2^b - 1$$n$$n + 1$$2^b - 1$$n + 1$

La sta per una variabile specifica per l'applicazione, generalmente 4 . Usiamo b = 4 , per semplicità. Quindi quanto sopra è$b$$4$$b=4$

La tabella di routing di un nodo, , è organizzata in ⌈ log 16 N ⌉ righe con 15 voci ciascuna. Le 15 voci alla riga n della tabella di routing ogni riferimento ad un nodo il cui nodeId azioni NodeID presente nodo nel primi n cifre, ma il cui n + 1 esima cifra ha uno dei 2 b - 1 valori possibili diversa dal n + 1 digit ° nella presente id del nodo.$R$$\lceil \log_{16} N\rceil$$15$$15$$n$$n + 1$$2^b - 1$$n + 1$

Lo capisco molto. Inoltre, è il numero di server nel cluster. Lo capisco anche io.$N$

La mia domanda è: se la riga in cui viene inserita una voce dipende dalla lunghezza condivisa della chiave, perché il limite apparentemente casuale sul numero di righe? Ogni nodeId ha 32 cifre, quando (128 bit nodeIds divisi in cifre di b bit). Quindi cosa succede quando N diventa abbastanza alto da ⌈ registrare 16 N ⌉ > $b=4$$N$$\lceil\log_{16} N\rceil > 32$ ? Mi rendo conto che occorrerebbero 340.282.366.920.938.463.463.374.607.431.768.211.457 server (se la mia matematica è giusta) per colpire questo scenario, ma sembra solo una strana inclusione e la correlazione non è mai spiegata.

Inoltre, cosa succede se si dispone di un numero limitato di server? Se ho meno di 16 server, ho solo una riga nella tabella. Inoltre, in nessun caso ogni voce della riga avrebbe un server corrispondente. Le voci devono essere lasciate vuote? Mi rendo conto che sarei in grado di trovare il server nel set foglia a prescindere da cosa, dato che pochi server, ma lo stesso dilemma viene sollevato per la seconda riga - cosa succede se non ho un server che ha un nodeId tale che posso riempire ogni possibile permutazione dell'ennesima cifra? Infine, se ho, diciamo, quattro server e ho due nodi che condividono, diciamo, 20 delle loro 32 cifre, con qualche fluke casuale ... dovrei popolare 20 righe della tabella per quel nodo, anche se questo è molto più file di quanto potrei persino avvicinarmi al riempimento?

Ecco cosa ho escogitato, cercando di ragionare su questo:

1. Le voci devono essere impostate su un valore null se non esiste un nodo che corrisponda esattamente a quel prefisso.
2. Le righe vuote devono essere aggiunte fino a quando non sono presenti righe sufficienti per corrispondere alla lunghezza condivisa degli nodeIds.
3. Se, e solo se, non esiste una voce corrispondente per un ID messaggio desiderato, tornare indietro alla ricerca della tabella di routing per un nodoId la cui lunghezza condivisa è maggiore o uguale all'attuale nodoId e la cui voce è matematicamente più vicina all'attuale nodeId corrisponde all'ID desiderato.
4. Se non è possibile trovare un nodo adatto in # 3, supponiamo che questa sia la destinazione e recapita il messaggio.

Tutte e quattro queste ipotesi reggono? C'è un altro posto dove dovrei cercare informazioni su questo?

1. Pastry: localizzazione e instradamento di oggetti scalabili e decentralizzati per sistemi peer-to-peer su larga scala di A. Rowstrong e P. Druschel (2001) - scaricare qui

L'idea di una tabella di routing in Pastry (e in tutte le reti P2P strutturate) è di minimizzarne le dimensioni, garantendo al contempo un routing più rapido.

L'algoritmo di routing di Pastry è il seguente:

Passaggio A. Un nodo che cerca un oggetto A cercando innanzitutto nel suo insieme di foglie. Passaggio B. Se non era disponibile, la query viene inoltrata a un nodo noto che condivide "un numero di prefissi con che è almeno maggiore del nodo che condividi con A". Passaggio C. Se tale record non viene trovato, la query viene inoltrata a un nodo nel set di fogli che è numericamente più vicino ad $A$$A$ .

Questo è il motivo per cui un nodo $u$ memorizza gli indirizzi dei nodi organizza la sua tabella come segue:

$i$$u$$i$$u$

$(i + 1)^{th}$$i$$\{0, …, 2^{b} – 1\}$ .

$A$ ha l'identificatore 4324: allora ecco cosa accadrà: (assumiamo che sia della base di 4. (cioè gli indirizzi provengono da [1-4] [1- 4] [1-4] [1-4]).

$u$$A$$u$$A$$u$$u _1$$u _1$

$u _1$$A$

$log_{2^b}$$b$$2^b$$b$

Gli scenari pratici di solito non sono tipici di questo. Ci possono essere situazioni in cui non ci sono molti nodi nella rete. questo è il motivo per cui seguiamo il passaggio C sopra. - Tuttavia, ciò che è necessario garantire per correggere questo algoritmo è che ciascun nodo sia collegato ai due nodi più vicini (in termini di identificatori). Questo formerà un anello di nodi ordinati [ad es. 1-> 3-> 4-> 9-> 10-> 11-> 1]