Newsgroup: it.comp.macintosh
Titolo: Re: un mezzo di ottì: due adsl da 4 mega appaiate per andare a 8...

 
puoi farlo ma per avere davvero il raddoppio di banda per una singola 
connessione, devi avere anche il supporto del provider. NGI ad esempio 
lo prevede (cerca F5 4 mega), avendo un router con supporto multilink (o 
una linuxbox appositamente configurata), puoi effettivamente avere 
l'affasciamento di due (o più) linee adsl.

 soluzione) facesse il lavoro di smistamento pacchetti...
Infatti che io ricordi si può fare in questa maniera.
Chiaramente è la banda complessiva che aumenta cioè ogni connessione tcp 
andrà o su una o sull'altra linea, hai aumentato il parallelismo però.

 La macchina linux si occupa del routing e fa anche da firewall.
Monowall: 4 schede di rete, due ai modem, una alla Lan e l'altra per la
gestione.
Lo fece un mio conoscente con una linea fastweb ed una 191 Business per
l'ip fisso.
-- 
"Those who try to lead the people 
can only do so by following the mob"
Oscar Wilde
http://www.cieloprovvisorio.net

 andrà o su una o sull'altra linea, hai aumentato il parallelismo però.
ecco,
puoi fare anche così, ma come dicevo io hai il raddoppio di banda per 
ogni singola connessione (analogamente a isdn su doppio canale).

 parallelismo...
Lo dirò parafrando una nota pubblicità di Maxibon:
two lines is meglio che one.

 chiaro allora il senso del "però"
Riformulo:
anche se hai due linee adsl, supposte identiche tra loro, la singola 
connessione tcp ha lo stesso limite di velocità di quando avevi una sola 
linea _però_ puoi avere due connessioni alla velocità massima in 
parallelo.

 parallelo.
Sai che non sono sicuro di questo? I diversi pacchetti di una stessa
connessione TCP possono viaggiare senza problemi anche su percorsi
diversi.
-- 
Soon there'll be just two kinds of people.
Those who use computers.
And those who use Apples.

 Sai che non sono sicuro di questo?
Anzi, dopo averci rimuginato un po' su, sono quasi convinto del
contrario... Il routing avviene al livello IP e a questo livello la
"connessione TCP" neanche esiste, esistono solo dei pacchetti che devono
raggiungere il loro destinatario e ciascun pacchetto è un'entità
autonoma, che può essere smistato lungo percorsi diversi. Ci penserà poi
il livello TCP del destinatario, una volta ricevuti i pacchetti dal
proprio livello IP sottostante, a rimettere in ordine il tutto.


 all'altra (da un IP pubblico all'altro) senza perderne la connessione.
Il NAT non lo avevo considerato ed effettivamente potrebbe complicare la
questione. Comunque ripeto, al livello IP parlare di connessione non ha
senso: l'IP è connection-less, ed è proprio questo uno dei suoi punti di
forza. La connessione tra i due host è un'astrazione che fa il TCP, ma
per il TCP il routing è assolutamente trasparente...


 vedono te, ma il tuo IP pubblico. Se cambi linea cambi IP pubblico.
No, ci ho ripensato bene e il NAT non dovrebbe costituire alcun
problema. La situazione, se non ho capito male, č questa: una macchina
(router o linux-box che sia) che ha due interfacce di rete WAN (piů
ovviamente almeno un'interfaccia LAN), ognuna col suo modem adsl
attaccato e ognuna col suo IP ricevuto dal provider: nel caso di modem
gli indirizzi delle interfacce WAN sarebbero reali, nel caso di
modem/router potrebbero essere NATtati, ma la cosa non creerebbe
problemi, perché sono due NAT indipendenti, ciascuna su una diversa
interfaccia. Quando il dispositivo riceve dei pacchetti da una macchina
della LAN, tutti indirizzati allo stesso IP di destinazione esterno alla
LAN, il dispositivo, se puň essere configurato per gestire il load
sharing tra le due interfacce, potrebbe smistare parte dei pacchetti
verso una delle due interfacce WAN e la restante parte verso l'altra.
Quindi in upload potrebbe arrivare in teoria a sommare l'ampiezza di
banda delle due connessioni. Il problema potrebbe esserci nel download:
se i router intermedi non sanno che possono raggiungere l'IP della
macchina in questione seguendo due vie diverse, i pacchetti potrebbero
essere inviati solo verso una delle due connessioni DSL.
In sintesi: non so se la cosa sia fattibile, ma gli eventuali problemi
sono unicamente dovuti a come č gestito il routing dal router/linux-box
e dai router dei provider. Socket, connessioni e tutto quanto riguardi
il livello TCP non c'entra nulla...


 perché la nuova route venga recepita e diventi effettivamente attiva.
Non è l'ARP: l'ARP serve a trovare il MAC address relativo a un certo
indirizzo IP. Non ricordo ora come si chiamano i messaggi con cui i
router si comunicano le reti conosciute: credo dipenda anche dai
particolari protocolli. Comunque tornando alla questione: non si tratta
di sostituire un percorso con un altro, ma di sapere che esistono
entrambi i percorsi. I protocolli di routing più evoluti lo fanno
tranquillamente e il load sharing tra percorsi diversi per raggiungere
la stessa destinazione è prassi comune.


 la stabilità del socket.
Non cambia nulla: tutti quelli che citi sono protocolli che stanno sopra
al TCP; il routing e tutto ciò che gli è connesso (come il load sharing
che vorresti fare tu) riguardano il livello IP, che sta sotto al TCP...
Come dicevo, gli unici problemi potrebbero derivare da come è gestito il
routing verso le utenze domestiche.



allora,
per semplificare:
caso 1: solo linuxbox con 2 modem adsl, due linee 2048/512, puoi avere 2 
download di file distinti simultanei, ciascuno a 2048; velocità massima 
in upload 512 per trasferimento
caso 2: linuxbox in multilink ppp/router apposito *e* supporto allo 
stesso da parte del provider, puoi avere un singolo download a 4096 o 
upload a 1024.
Lo dico per esperienza in quanto ho messo giù parecchie di queste linee 
affasciate.
Spero di essere stato d'aiuto,
ciao

 problema.
Su questo mi correggo: il NAT non deve esserci.


 Sta di fatto che -come notavi dall'altra parte- il NAT frena tutto.
Sě, vero. Non consideravo che se l'interfaccia WAN della linux-box
riceve un indirizzo di NAT dal modem/router DSL, a maggior ragione gli
indirizzi IP delle macchine in LAN non possono essere indirizzi IP
"reali"...


 già una bella scommessa far propagare il RIP...
Come diceva lo, la cosa può funzionare solo coll'opportuno supporto da
parte del provider. Che poi, a pensarci bene, la cosa importante è che
sia il provider a supportare il load sharing da e verso l'utente: fino
al (e a partire dal) provider i pacchetti potrebbero anche seguire
tranquillamente tutti lo stesso percorso...


 più veloce? Non costerebbe anche meno? (chiedo, eh, magari è "no").
Di solito l'affasciamento avviene tra linee da 2000/512, le 4 mega
singole in download che io sappia non danno garanzie (per il modo in
cui Telecom le vende agli altri).
Se vuoi una linea *simmetrica* HDSL spendi di più che prendere 2 adsl
(in media) a parità di upload, ma sono prodotti diversi; intanto
l'HDSL la puoi avere ovunque, la latenza è molto più bassa ed i tempi
di intervento più tempestivi.
D'altra parte ci sono adsl professionali che viaggiano da paura (tipo
quelle di mclink, ad es la Corporate che appunto prevede
l'affasciamento).
Gabriele

 ci metto molto a chiedere ad un avvocato (uno bravo, intendo ;) )
Più che un avvocato, vai a sentire che dicono all'ufficio territoriale
delle Poste e Comunicazioni della tua città.
Visto che sono loro che danno le autorizzazioni eventuali :)
Gabriele
ps: vieni su it.tlc.telefonia.voip così magari trovi qualcuno che
genera molto traffico VoIP e ti può dare dei consigli.

 l'ip fisso.
Questo non c'entra nulla con quanto richiesto da EvanMac, che ha
bisogno di banda in entrambe le direzioni.
Gabriele

 Quali e` la latenza media per una connessione HDSL e quella per una ADSL?
Posto che la latenza non è un valore fisso scolpito nella pietra,
secondo me una buona HDSL può avere una latenza di 10/15 ms, contro il
doppio (a crescere) di un'adsl (che poi può essere 'fast' o
'interleaved', dipende dall'isp e da cosa devi farci).
Gabriele