<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Non conosco questa soluzione, ma, a naso, credo che non faccia al caso nostro. TCP? Hai link?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Quando hai l'esigenza di offrire un canale logico più ampio hai principalmente 3 strade:</div><div class="gmail_default"><ul><li><font face="monospace, monospace">bonding L2 con collaborazione dell'ISP (es. ML-PPP, con un piccolo fix del kernel per disattivare la frammentazione)</font></li><li><font face="monospace, monospace">bonding L2 over L7 senza collaborazione dell'ISP, più inefficiente ma compensato dall'economicità(?) (es. l'accrocchio di Daniele Capasso)</font></li><li><font face="monospace, monospace">load-balancing L3 (es. Multipath routing nativo o politiche gestite da netfilter), con efficienza direttamente proporzionale al numero degli utenti/flussi e senza overhead</font></li></ul><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Diciamo che in contesti abbastanza saturi, ovvero con flussi di gran lunga maggiori del numero dei singoli canali e con capacità del singolo canale maggiore di quella che si vorrebbe offrire all'utente finale,</font></div><div><font face="monospace, monospace">la strada migliore, a mio modo di vedere, è un banale load-balancing.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">In altre parole, se hai delle misere ADSL da 7Mbit e vuoi dare all'utente finale la brezza di andare a 20Mbit (almeno come burst), allora devi bondare in qualche modo. Se invece hai a disposizione FTTCAB da 50-100Mbit, allora non mi stresserei l'anima a fare accrocchi o bonding, tanto all'utente finale arriverebbe comunque una banda inferiore a causa dei limiti del WiFi.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Questo TCP Multipath di cui parli può permettere di streammare all'utente finale un flusso audio-video live con bitrate maggiore di quello del singolo canale? Se la risposta è NO, allora non fa assolutamente al caso nostro.</font></div><div><font face="monospace, monospace">Tanto vale fare load-balancing.</font></div><div><font face="monospace, monospace"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 24 dicembre 2016 19:40, Massimiliano CARNEMOLLA <span dir="ltr"><<a href="mailto:massimiliano@null.net" target="_blank">massimiliano@null.net</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">C'e' chi ha dovuto affasciare ADSL per unire i flussi in download/upload di piu' connessioni, chi ha utilizzato server su Internet per fare la stessa cosa.<br>
<br>
<br>
Dentro Ninux Roma utilizzano il TCP Multipath per ottenere lo stesso obiettivo.<br>
<br>
<br>
Nei vs casi non era possibile utilizzare questa soluzione ?<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Wireless mailing list<br>
<a href="mailto:Wireless@ml.ninux.org" target="_blank">Wireless@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/wireless" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/li<wbr>stinfo/wireless</a><br>
</div></div></blockquote></div><br></div></div>