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