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