si questo e' il discorso esaminato nelle sue casistiche, praticamente abbiamo quindi visto che per un nodo che si muove il max che si puo' fare e' qualcosa tipo fast-olsr ( cmq i 150km/h non interessavano a me ma sono quelli riportati nei loro "studi" ) che da quello che dicono funziona anche abbastanza bene ora bisogna trovare il sorgente o riscriverlo ( dalla spiegazione che fanno non sembra troppo complicato )
nel caso due bisogna vedere come fare un'idea era usare una subnettona gigante per tutti i client cosi' che spostandosi da un nodo all'altro non sia necessario cambiare ip ma a questo punto bisogna vedere come si comporta l'instradamento verso la nuova strada On Saturday 27 February 2010 10:43:57 Antonio Anselmi wrote: > la caduta di chiamate non dipende tanto dalla velocita' con cui ti > muovi ma dal conseguente fatto che cambiando il path (la route) devi > rinnovare gli handshake TCP con il next hop. Ergo: quanto piu' a lungo > la route e' considerata valida (anche se degradata) minore e' il > rischio di connessioni TCP abbattute (poprio perche' cambia il > gateway). > > olsrd usa l'algoritmo "shortest path first" per quanto riguarda il > mantenimento dello status di un link (almeno le versioni RFC > compliant...). Ora supponiamo che: > > - al tempo t0 sei collegato al gateway G con un solo hop (te -> nodo G) > - al tempo t0+n e' *disponibile* una rotta migliore: te -> > nodo-intermedio -> nodo G (2 hop) > > orbene, olsrd privilegia il link con un solo hop (con ETX povero) a > dispetto due hop (ciascuno con ETX migliore). Questo "dovrebbe" > garantire una certa persistenza delle connessioni TCP, perlomeno in > presenza di una mobilita' "circolare", ovvero ti muovi gironzolando e > NON orizzontalmente "in fuga". > > Ma non bisogna esagerare nel tenersi "stretta" una rotta che - piu' o > meno velocemente - sta' degradandosi, e qui entra in gioco la > velocita'. > Occorre anche stimare il ritardo tra "quando" la route e' andata > definitivamente a fangala e "quando" (invece) olsrd ne prendera' atto. > Ovvero riflettere sia su gli intervalli con cui le informazioni sono > aggiornate (Hello e TC interval) sia sul periodo di tempo durante il > quale quelle informazioni sono considerate attendibili *anche* in > assenza di un loro aggiornamento (soft state). Un soft state > eccessivamente conservativo rischia di mantenere come praticabili > rotte che in realta' sono cadute. > > Diminuendo i due valori HelloInterval e HelloValidityTime otterremo > sicuramente un demone piu' reattivo ai cambiamenti di topologia ma > aumenteremo - e non di poco - l'overhead (la vita e' un compromesso). > > In buona sostanza, email, web o chat (o streaming video se > bufferizzati) non creano grossi problemi mentre il voip ne risente in > misura maggiore. > > Ma non e' finita qui.... > > Altre considerazioni devono essere fatte a seconda che il terminale > skype stesso esegua olsrd (ed e' quindi lui stesso un nodo del mesh!) > oppure se il termnale skype si connette ad un nodo meshato (magari > statico, montato su un palo) che esegue olsrd. > In questo ultimo caso non e' la mobilita' del nodo mesh che deve > essere presa in considerazione (e quindi tutto l'ambaradan di olsrd) > bensi' la mobilita' di un client nei confonti di un AP. > > ...post poco adatto per un sabato mattina (quasi) primaverile, ma mi > e' presa cosi' :) > > > Antonio > > Il 27 febbraio 2010 04.08, Filippo Sallemi <tonyp...@gmail.com> ha scritto: > > Gioacchino intende questo.... > > se io sono in un parco comunale, tipo villa margherita, e mi muovo a > > piedi trai nodi, come faccio a non far cadere la mia chiamata skype? > > Ovviamente lui pensa in grande e 150 Km/h sono tanti, a me ne > > basterebbero 1/3 per far contentala gente... e sarebbero costretti a non > > correre :-) Ovviamente la risposta più banale è IPv6 ma non sono io > > l'esperiente in merito. > > Ciao > > > > Il giorno 26 febbraio 2010 20.08, Reiser4 <reis...@gmail.com> ha scritto: > >> Il giorno 26 febbraio 2010 19.56, Gioacchino <gmazzurc...@gmail.com> ha > >> > >> scritto: > >>> ciao ragazzi > >>> cercando come si comporta olsr con al mobilita' ho trovato informazioni > >>> su un > >>> plugin chiamato fast-olsr con tanto di simulazioni che dice di avere a > >>> 150km/h > >>> una perdita di pacchetti del 15% ma cercando il sorgente o comunque un > >>> modo > >>> per poterlo usare ho trovato solo un'archivio su una pagina di un > >>> professore > >>> francese che contiene cose che il mio pc dice che sono script mathlab > >>> ma se li > >>> apro con un editor di testo mi dice che sono binari infatti del testo > >>> si riesce a leggere solo qualcosa il resto sono simboli strani > >>> > >>> cosa ne sapete/pensate voi ? > >> > >> andando a 150km/h hai perso per strada la punteggiatura? non capisco la > >> finalità del mesh a 150km/h nè come possa un plugin cambiare la > >> situazione. Spiegaci cosa vuoi fare che ci pensiamo su.. > >> Enrico > >> > >> _______________________________________________ > >> Wireless mailing list > >> Wireless@ml.ninux.org > >> http://ml.ninux.org/mailman/listinfo/wireless > > > > -- > > Filippo Sallemi > > > > _______________________________________________ > > Wireless mailing list > > Wireless@ml.ninux.org > > http://ml.ninux.org/mailman/listinfo/wireless > > _______________________________________________ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless _______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
