Praticamente, come funziona ?
Sfrutto l'upload di piu' connessioni ad Internet ?
E' possibile fare la stessa cosa con i download ?
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
si da firefox
Il 06 aprile 2014 22:08, Germano Massullo germano.massu...@gmail.com
ha scritto:
Il 06/04/2014 20:20, Clauz ha scritto:
Potresti provare proxandoti?
http://wiki.ninux.org/ProxyHTTP
Clauz
___
Wireless mailing list
Unica cosa ci sta la possibilità che non sia stabile, il proxy è usato
da diverse persone e non ci sono delle policy di qos ovviamente.
Io pure ci carico a 5-6 mega in upload.
Il 06/04/2014 21:04, Saverio Proto ha scritto:
Usa il proxy
http://wiki.ninux.org/ProxyHTTP
io carico su Vimeo a
Giusto per completezza, comunico che l'utilizzo del proxy sarà limitato
solo al pomeriggio nel quale avrò bisogno di un'elevata banda di upload,
così da non abusare del mezzo.
___
Wireless mailing list
Wireless@ml.ninux.org
sta li per essere usato.
piu lo usiamo meglio e'.
Saverio
Il 07 aprile 2014 16:32, Germano Massullo germano.massu...@gmail.com
ha scritto:
Giusto per completezza, comunico che l'utilizzo del proxy sarà limitato
solo al pomeriggio nel quale avrò bisogno di un'elevata banda di upload,
così da
Saverio una domanda : ma quel proxy ha qualche password ?
Date: Mon, 7 Apr 2014 17:29:06 +0200
From: ziopr...@gmail.com
To: wireless@ml.ninux.org
Subject: Re: [Ninux-Wireless] Multipath TCP
sta li per essere usato.
piu lo usiamo meglio e'.
Saverio
Il 07 aprile 2014 16:32, Germano
Tra pochi giorni avrei bisogno di massimizzare l'upload della rete per
uno stream di poche ore su UStream (o su Youtube, la cosa è ancora da
decidere).
Vorrei sapere se con il multipath TCP è possibile utilizzare la banda in
upload dell'ADSL insieme a quella di Ninux. In caso affermativo, come
Multipath tcp richiede che ambedue gli endpoint abbiano tale estensione.
Quindi a meno che ustream o youtube non abbiano il supporto per questo
protocollo non lo puoi usare.
Inoltre non ti consiglio di usare per un applicazione real time un
sistema multiwan per l'upload dello stream, il jitter
Il 06/04/2014 13:59, Alessandro Gnagni ha scritto:
Ti conviene cercare di massimizzare la banda da un unico exit point.
Purtroppo è questo il problema, in quanto l'ADSL va solo a 0,38 Mbit/s
in upload.
___
Wireless mailing list
Wireless@ml.ninux.org
On 04/06/2014 03:30 PM, Germano Massullo wrote:
Il 06/04/2014 13:59, Alessandro Gnagni ha scritto:
Ti conviene cercare di massimizzare la banda da un unico exit point.
Purtroppo è questo il problema, in quanto l'ADSL va solo a 0,38 Mbit/s
in upload.
Potresti provare proxandoti?
Usa il proxy
http://wiki.ninux.org/ProxyHTTP
io carico su Vimeo a 10Mbps circa col proxy
Saverio
Il 06 aprile 2014 20:20, Clauz cl...@ninux.org ha scritto:
On 04/06/2014 03:30 PM, Germano Massullo wrote:
Il 06/04/2014 13:59, Alessandro Gnagni ha scritto:
Ti conviene cercare di massimizzare
Il 06/04/2014 20:20, Clauz ha scritto:
Potresti provare proxandoti?
http://wiki.ninux.org/ProxyHTTP
Clauz
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Il 06/04/2014 21:04, Saverio Proto ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/04/2013 11:50, Alessandro Gnagni wrote:
Interessante. Ma nn credo si possa applicare alla nostra rete,
almeno non utilizzando olsr.
qualcuno saprebbe dirmi se in una rete totalmente ad-hoc, magari con
batman-adv, sarebbe possibile instradare
On Tuesday 14 May 2013 14:43:20 Gabriel wrote:
qualcuno saprebbe dirmi se in una rete totalmente ad-hoc, magari con
batman-adv, sarebbe possibile instradare più subflow tcp su route diverse?
batman-adv crea un gigantesco switch quindi da layer 3 in su e' trasparente
come uno switch
On Tuesday 14 May 2013 16:22:43 Gabriel wrote:
certo, ma non sceglie in base allo stato del link il percorso su cui
instradare i frame?
non è possibile quindi che, se un percorso è congestionato, uno dei
subflow faccia un altro giro?
si certo ma questo dipende dalle rotte che hai che sono a
Si ma in quel caso devi gestirlo a livello applicativo, qui invece lo puoi
gestire in maniera trasparente rispetto all'applicativo usato.
IMHO forse Alessandro dobbiamo provarlo, nessuno ha la risposta in tasca.
se l'applicazione legacy apre un socket TCP/IPv4, poi non e' detto
che il Kernel
Ovvio che posso tirare su una macchina virtuale ^^
Appena ho un attimo di tempo lo faccio.
Inviato da Nexus 7
Il giorno 24/apr/2013 10:48, Saverio Proto ziopr...@gmail.com ha
scritto:
Si ma in quel caso devi gestirlo a livello applicativo, qui invece lo
puoi
gestire in maniera trasparente
Se volete provare c'è questa macchina con il kernel patchato per mptcp:
mptcp-cloud.dnsaas.it
La macchina ha anche un indirizzo ipv6 e c'è un iperf (tcp) che gira sulla 5001.
C'è anche un grosso file da scaricare:
http://mptcp-cloud.dnsaas.it/Fedora-18-x86_64-DVD.iso
La banda li non dovrebbe
esatto ! :)
Il giorno martedì 23 aprile 2013, Alessandro Gnagni ha scritto:
Ahhh. Ho capito cosa vuoi ottenere... Vuoi vedere se con più flussi
compensi le limitazioni dovute alla latenza della rete.
Inviato da Nexus 7
Il giorno 23/apr/2013 00:55, Saverio Proto
No, non e' la latenza... se il media e' lo stesso per tutti i flussi
puoi ridurre l'impegno a vuoto del canale. E' piu' per una questione
di robustezza della connessione ed efficenza nello sfruttamento della
risorsa trasmissiva:
- gestione dell'hand-over,
- ridurre il numero di sessioni
Diciamo che la latenza e' intesa nel contesto della trasmissione globale,
non della singola sessione TCP. Penso che Saverio ed Alessandro abbiano
asserito al fatto che con il multipath TCP olsr piuo' instradare i flussi
in piu' direzioni nel caso in cui c'e' un ingorgo sulla tangeziale, passa
per
Ciao,
mi hanno fatto vedere questo progetto:
http://multipath-tcp.org/pmwiki.php?n=Main.HomePage
da leggere con attenzione :)
per iniziare se si parte da 0 consiglio la lettura di questo breve articolo
http://lwn.net/Articles/544399/
Saverio
___
Interessante. Ma nn credo si possa applicare alla nostra rete, almeno non
utilizzando olsr.
Il giorno 22/apr/2013 11:44, Saverio Proto ziopr...@gmail.com ha
scritto:
Ciao,
mi hanno fatto vedere questo progetto:
http://multipath-tcp.org/pmwiki.php?n=Main.HomePage
da leggere con attenzione
Interessante. Ma nn credo si possa applicare alla nostra rete, almeno non
utilizzando olsr.
mi interessa provare piu subflow TCP anche se insistono sullo stesso path.
Saverio
___
Wireless mailing list
Wireless@ml.ninux.org
Ahhh. Ho capito cosa vuoi ottenere... Vuoi vedere se con più flussi
compensi le limitazioni dovute alla latenza della rete.
Inviato da Nexus 7
Il giorno 23/apr/2013 00:55, Saverio Proto ziopr...@gmail.com ha
scritto:
Interessante. Ma nn credo si possa applicare alla nostra rete, almeno non
25 matches
Mail list logo
