11 Jan 2007 00:49
Re: netsukuku info
On Wed, Jan 10, 2007 at 03:52:17PM +0100, <Alessandro Ordine>: ~> Sto preparando una presentazione in inglese che tira le somme delle nostre ~> conversazioni, appena e' pronta te la mando cosi', se e' ok, la posso ~> estendere e si puo' inserire nella documentazione ufficiale. perfetto. ~> Viphilama non e' pensata per bilanciare il carico su i link fisici ma e' ~> pensata per estendere supplire all'assenza di nodi di netsuku fisicamente ~> vicini. si ~> Quello che mi piacerebbe fare (non mi chiedere come ;-P ) e' invece ~> costruire una rete virtuale sopra netsukuku in modo da ottimizzarla in ~> situazioni simili a quella che risolvete col "Multi-barycenter". Forse e' ~> una cazzata ma ci voglio pensare... che dici? Capito. Non e' un'idea malvagia, pero' devi introdurre qualche meccanismo di overlay che sia cosciente delle rotte e della situazione della rete su cui si appoggia l'overlay (i.e Internet). Viphilama non credo che possa aiutare, proprio perche' cerca di essere trasparente a Netsukuku, senza entrare nei dettagli della rete su cui si poggia, ma sfruttando solo le coordinate fisiche. Non so, ma si potrebbe approfondire. Se ti interessa lavorare su problemi teorici e sul load balancing, dai anche un'occhiata al Caustic Routing:(Continue reading)
Non proprio. Un TP e' limitato dentro un livello,
(adesso, aggiungendo i livelli, supponiamo che le discovery vengano effettuate
contemporaneamente in tutta la rete, per la prima volta),
quindi il calcolo e' un po' piu' complicato:
i pkt generati in un g1:
g1=256*256 # da ogni nodo, 256 TP
i pkt generati in tutti i g1 di tutta la rete:
(supponendo che la rete sia di 2^32)
gt1=g1*256^3
poi dobbiamo considerare che in ogni livello avviene una cosa simile.
Ma qual'e' il layout dei gnode? Usiamo un grafo completo anche in ogni
livello. Questo sarebbe il caso peggiore.
Quindi Phi_m sarebbe sempre 256, ma nel lvl 2, quando un TP passa
attraverso un gnode, raggiunge tutti i nodi al piu' una volta, quindi
g1=256*256*256
gt1=g1*256^2
g2=256*256*256*256
gt2=g2*256
g3=256*256*256*256*256
gt3=g3
In totale:
gt3+gt2+gt1 == 3298534883328 ~= 3.29 * 10^12
Ora pero', pensandoci un altro po', ci accorgiamo che questi conti sono
totalmente inutili. Infatti:
1) I TP vengono scambiati "localmente". 3298534883328 non e' il numero
di pkt scambiati tra tutti i nodi, ma e' il numero di pkt
generati/creati.
E' come se ogni nodo parlasse con il suo vicino e noi stessimo
contando il numero di pkt che si generano totalemente nella rete.
Ovviamente e' un numero enorme, perche' i nodi sono molti, pero'
il carico imposto a ogni nodo e' irrisorio: ogni nodo sta'
semplicemente parlando con il suo vicino.
In sostanza, e' sbagliato considerare i TP come pkt
broadcast/multicast.
Sempre in questo caso apocalittico, il conto che bisognerebbe fare
e' quello di vedere il carico imposto a ogni nodo:
Prima abbiamo visto che era 32Kb per un nodo di un gnode. Ora
consideriamo i livelli (sempre nella situazione di grafo
completo a ogni livello).
Da ogni gnode, passano 256 TP. Quello che importa qui e che da
ogni nodo del gnode, ne passano pure solamente 256. Quindi il
conto e' facile:
32*4Kb == 128 Kb
Quindi il carico imposto a ogni nodo, durante questa discovery
gigante e' di 128Kb!
2) Ora vediamo un po' alcune considerazioni pratiche:
a) E' quasi impossibile che si arrivi in uno stato in cui 2^32 nodi
sono gia' connessi tra loro, non hanno mai fatto una discovery,
e tutti contemporaneamente iniziano a farla.
La rete, invece, cresce discretamente: prima un piccolo core,
poi vari nodi si agganciano, e cosi' via. L'andamento potrebbe
essere anche esponenziale, ma non importa.
b) La probabilita' che 2^32 nodi si dispongano come un grafo
completo (e per di piu' a ogni livello), e' quasi pari a zero ;)
a dopo
RSS Feed