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
no
Il 07 aprile 2014 23:02, federico la morgia
ha scritto:
> 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
&
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'.
>
> Save
sta li per essere usato.
piu lo usiamo meglio e'.
Saverio
Il 07 aprile 2014 16:32, Germano Massullo
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 non abusare del mezzo.
>
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
http://ml.ninux.org/mailman/lis
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 Vime
si da firefox
Il 06 aprile 2014 22:08, Germano Massullo
ha scritto:
> 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
>>
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 Pro
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 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 la banda
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?
http://wik
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
htt
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 dive
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
biso
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
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
__
-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
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
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" ha
scritto:
> > Si ma in quel caso devi gestirlo a livello applicativo, qui invece lo
> puoi
> > gestire in maniera trasparente rispetto all'
> 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 Kerne
Si ma in quel caso devi gestirlo a livello applicativo, qui invece lo puoi
gestire in maniera trasparente rispetto all'applicativo usato.
Inviato da Nexus 7
Il giorno 24/apr/2013 10:00, ha scritto:
> Si potrebbero usare due o piu' protocolli di routing in parallelo,
> oppure sfruttare IPv4 ed IP
Si potrebbero usare due o piu' protocolli di routing in parallelo,
oppure sfruttare IPv4 ed IPv6 contemporaneamente per la stessa connessione.
Clauz
On 04/24/13 08:38, Alessandro Gnagni wrote:
> No. Con olsr non possiamo instradare il flusso per più direzioni. Tuttavia
> è stato notato che divide
No. Con olsr non possiamo instradare il flusso per più direzioni. Tuttavia
è stato notato che dividendo il flusso in più stream concorrenti si ottiene
una velocità superiore rispetto al singolo stream.
Quindi abbiamo notato che la somma delle parti è più dell'intero.
Il giorno 24/apr/2013 04:35, "G
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
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 interrott
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"
> >
> 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" ha
scritto:
> > Interessante. Ma nn credo si possa applicare alla nostra rete, almeno non
> > utilizzando ol
> 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
http://ml.ninux.org/mailma
Interessante. Ma nn credo si possa applicare alla nostra rete, almeno non
utilizzando olsr.
Il giorno 22/apr/2013 11:44, "Saverio Proto" ha
scritto:
> Ciao,
>
> mi hanno fatto vedere questo progetto:
>
> http://multipath-tcp.org/pmwiki.php?n=Main.HomePage
>
> da leggere con attenzione :)
>
> 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
___
Wir
29 matches
Mail list logo