Come si diceva in un altro thread, la rete mesh non riesce a sostenere traffico di tipo p2p.
Perchè? Problema di banda? In realtà no, perchè l'uscita verso Internet è molto piu lenta del throughput della rete. I problemi sono che: 1) su 802.11 quando perdi un pacchetto la situazione è tragica, perchè ci vuole un sacco di tempo per rispedirlo (ovviamente facendo il paragone con 802.3) 2) ip_conntrack è caricato di Default nella maggior parte dei firmware, e fatica a gestire un elevato numero di connessioni TCP su hardware embedded Ora notate che da precedenti discussioni su MTU è venuto fuori che quando il modulo ip_conntrack è caricato nel kernel, se arriva un pacchetto IP frammentato, si aspetta l'altro frammento prima di spedire il tutto, anche se non ci sono NAT o regole di firewall particolari: http://www.archivum.info/netfilter/2002-02/msg00243.html Questo taglia le gambe al p2p. Infatti credo che lo strozzo sia la CPU e la RAM del router che vengono monopolizzate dal modulo ip_conntrack quando il numero di connessioni TCP cresce troppo. Se vi ricordate i primi D-Link con Kernel Linux morivano a causa del p2p se si facevano troppe connessioni TCP Nel caso di pacchetti IP frammentati poi la probabilità di perdere un pacchetto IP cresce, perchè diviso due due Frame 802.11 si deve tenere conto delle due probabilità di perdita dei due frames correlate tra di loro. Per verificare questo in modo serie, di potrebbero fare delle prove su una mesh dove su tutti i router si disabilita ip_conntrack. Ovviamente niente piu firewalls e NAT poi :) Un monitoraggio generale con SNMP e poi vediamo i dati :) my 2 cents. Saverio
