-English version at bottom- :::::::::::::::::::::::::::ITALIAN:::::::::::::::::::::::::::::::::::::
Ciao a tutti, vi seguo da un po' ma non mi sono mai fatto vivo :p Siccome Netsukuku è pensato per nodi "statici", quindi non del genere cellulari, ho pensato ad una possibile implementazione per dispositivi mobili che riporto qui sotto... -Si suddivide tutta la rete Netsukuku in 2 grossi gruppi: Nodi Statici (NS)e Nodi Mobili. (NM)* -I NS sono normali nodi. -I NM contengono SOLO le seguenti informazioni: 1- Nodi raggiungibili direttamente (ad 1 hop) 2- Contengono le classiche "mappe interne" del nodo a cui sono assocati. ** -vedi fondo- -Associazione del NM (solo a NS): -Ricerca dei punti di associazione disponibili e scelta del migliore per rapporto Banda/Latenza o qualcosa di simile, magari considerando anche il numero di NM che un NS ha già associati... La ricerca viene eseguita ogni secondo se non vengono trovati nodi disponibili o se ne trova uno solo, ogni 2-3 secondi se i nodi disponibili sono 2, ogni 5 sec se i nodi sono 3 e per più di 3 nodi aumentiamo a 10 secondi. Nel caso si usino le mappe interne dei NS associati si può aumentare un pochino i tempi magari. -Viene mandato un normale CTP che girerà la rete. questo CTP anzichè essere della forma: IPM1---IPS2---IPS3--IPS4 dove IPS: ip di un nodo Statico e IPM: ip di un nodo mobile sarà nella forma: IPM1:IPS2---IPS3---IPS4 In modo che sia chiaro che per raggiungere IPM bisogna dirigersi verso IPS. Questo aumenterà sensibilmente le dimensioni della mappa interna/esterna ma credo sia il metodo migliore. Comunque l'idea è questa, ovvero dirigersi nella zona di IPM1. Per farlo dobbiamo dirigersi a IPS2 in questo caso. Una volta arrivati in zona ci sarà chi conosce esattamente dove è l'NM con ip IPM1. Il pacchetto verrebbe mandato a IPM, ma il software di routing lo instrada verso IPS2, poiché ha registrato IPM1:IPS2 nella mappa.... -Spero abbiate capito, perché non sono bravissimo a spiegare... :p NOTA:Si suppone che nel caso di uno spostamento il NM non cambi ip Ora, nel caso il NM si spostasse e dunque cambiasse nodo a cui è associato, da NS1 a NS2, quello che dovrebbe succedere è: -NM comunica a NS2 che ha deciso di SPOSTARSI su di lui. Si può eseguire una scansione dei nodi disponibili a questo punto. -In caso di connessioni attive da parte di NM, NS2 comunica a NS1 di passargli tutti i pacchetti che ancora arrivano a NS1. Qui serve qualche sistema di verifica. Magari direttamente in Carciofo? -Nello stesso tempo, dato che è uno spostamento, non parte un CTP come per la prima associazione, ma un TP limitato, diciamo 10 hop, e chiamiamolo LTP (Limited Tracer Packet). L'LTP funzionerà come il CTP, ma dovrà terminare dopo 10 hop. -Dopo 7 spostamenti se il NS1 è a più di 7 hop il NM fa partire un altro CTP. Se il NS1 è a meno di 7 hop non parte un CTP ma un normale LTP e il controllo sugli hop dal NS1 anzichè ogni 7 spostamenti viene ripetuto ogni spostamento. Questo serve per evitare di floodare la rete di CTP... anche se così rischiamo di floodare alcuni segmenti... Ovviamente aumentando il numero di hop nel LTP o aumentando il numero di hop prima del sucessivo CTP si può ritardare l'invio dei sucessivi CTP... alla peggio per un tratto i pacchetti ripercorreranno il percorso degli spostamenti di NM... generalmente dubito servano ping di 1ms quando si usano dispositivi mobili, per cui non dovrebbe essere un grosso problema. *-Si potrebbe specificare nel file di configurazione di netsukuku il tipo di nodo, oppure basterebbe controllare ogni quanto cambia il/i nodi a cui si è associato... **-Potrebbe aiutare a calcolare quale sia il nodo migliore in relazione anche ai circostanti o semplicemente per calcolare prima su quale nodo ci si può spostare in seguito. Inoltre inserendo queste mappe anche i NM dovrebbero potere fare routing di pacchetti... Senza le mappe a dire il vero i NS non dovrebbero contare i NM per il routing dei pacchetti... per cui forse è meglio farle prendere dal NS a cui sono associati... :::::::::::::::::::::::::::ENGLISH::::::::::::::::::::::::::::::::::::: --I'm Italian so i apologize if i made some mistakes when translating this letter.-- Hello to everyone, I followed Netsukuku development but i never said a word here :p Since Netsukuku was thought just for "static" nodes, not for mobile phones or similar, I though of a possible way to integrate even mobile devices... it's all down here :) - We separate the whole Netsukuku network in 2 groups: Static Nodes (SN) and Mobile Nodes (MN)* - SN are normal Netsukuku nodes. - MN have just these informations: 1- Directly contactable nodes (1 hop) 2-Classic "internal maps", borrowed from the SN to which they're associated. ** - How MN associate with a SN: - MN searches reachable SN and chooses the one with better Bandwith/Latency characteristics or something similar... maybe considering even how many MSs a SN already has... The search is done every second if no more than 1 SN is found, every 2-3 seconds if only 2 stations are found, every 5 seconds if we have 3 SN reachable, and 10 seconds for more SN. In case we use the internal maps of a SN, we can delay the search more. -A normal CTP is sent. this CTP instead of being in the form: IPM1---IPS2---IPS3--IPS4 like now, where IPM1 is the ip of a MN and IPS the ip of a SN will be in this form: IPM1:IPS2---IPS3---IPS4 So that it's clear that to reach IPM you have to go in IPS2 direction. This will increase a little the map dimension but i think it's the best method. This is the idea: go in IPM area. to do this, we have to go in IPS2 direction. When we'll be in IPS2 area (or when we finally get to IPS2), we'll know where IPM is. The packet will be sent to IPM, but the routing software should send it towards IPS2, since it has IPM1:IPS2 in its map - I hope you understood, actually i'm not very good at explaining this... :p NOTE: MN should not change ip when moving from a station to an other Now, in case MN moves and changes the SN to which its assiciated from SN1 to SN2, this is what should happen: -MN says to NS2 that it has decided to MOVE to him. Now MN can scan again for reachable nodes.... -If any connection from/to MN are still active, MN says to SN2 to say to SN1 to send to SN2 every MN-packet that still arrives to SN1. We need some way to verify the whole thing here... maybe directly in Carciofo? -In the same time, since this is a MOVE, MN does NOT send a CTP, like the first association, but a TP limited for, let's say, 10 hops. Let's call this tp LTP (Limited Tracer Packet). This LTP works just like the CTP, but terminates after 10 hops. -After 7 moves, if SN1 is at more than 7 hops (or is no more reachable), MN starts an other CTP. If SN1 is at less then 7 hops MN does not start a CTP but just a normal LTP, and the control of the distance(hops) from SN1 is repeated every move. This is not to flood the whole net with CTPs... but this way we risk to flood some single semgents... Obiviously if we increase the hop-limit in the LTP, or the hop-limit before the next CTP we can delay the next CTP...at the worse the packets will repeat the same road the MN made when moving... Since i dubt you need 1ms pings when moving with a mobile device, maybe it's not a big problem... *-The difference between a Mobile Node and a Static Node can be specified in the configuration file, or we can check if the near nodes change frequently.... **-Having maps in mobile devices can help calculating the best ap nearby, or just to know before to which node associate... Moreover inserting maps even MN could do some packet-routing... Without maps SN can not contact MN for packet-routing, so I think it's better to take the maps from the associated nodes... Aspetto risposta, Waiting a reply, Luca.
_______________________________________________ Netsukuku mailing list [email protected] http://lists.dyne.org/mailman/listinfo/netsukuku
