hard-limit connessioni TCP

[cionci]

Originariamente inviato da 71104

ribadisco il discorso del multicast: se gli ISP lo ammettessero farebbero un favore a se stessi prima che a noi, perché il P2P sarebbe N volte più efficiente con N calcolato come una stima media del numero di peers che richiedono un file in una rete P2P (cento? mille? diecimila?). e il P2P è solo un esempio di ciò che migliorerebbe.

Mantenere un traffico multicast su internet è estremamente costoso, prima di tutto perché necessita di meccanismi di subscribe/unsubscribe nei router intermedi (altrimenti come lo inoltri il traffico ? Fai un fllooding ?), meccanismo poi che non è molto sicuro.

[cionci]

Originariamente inviato da pisto

ma del cmodo in cui il protocollo tcp gestisce la velocità del flusso, meccanismo che si basa se ho capito bene sui pacchetti che vengono persi nel tragitto per qualsiasi motivo e la cui mancanza viene recepita da tutt'e due gli host. sono sempre speculazioni cmq.

Sì...in TCP il controllo di flusso e di congestione viene gestito proprio grazie ai pacchetti scartati dai router intermedi. Si assume che se si perde un pacchetto questo sia dovuto alla congestione.
Chiaramente aumentando il numero dei router intermedi la possibilità che uno o più di questi sia in congestione aumenta.
Ci sono i vari protocolli per la gestione della congestione che si basano tutti su una stima del RTT per sapere entro quando deve arrivare il nuovo pacchetto.

Comunque adesso stanno cominciando a venire fuori TCP di tipo ECN (Explicit Congestion Notificaiton), in pratica il controllo della congestione è gestito esplicitamente tramite un bit all'interno dell'header TCP. Vista che io sappia è uno dei primi SO ad avere il supporto ECN ed è per questo che molti router hanno avuto problemi di compatibilità con Vista. Il bit può essere settato sia da uno degli endpoint che dai router intermedi.

Originariamente inviato da cionci

Mantenere un traffico multicast su internet è estremamente costoso, prima di tutto perché necessita di meccanismi di subscribe/unsubscribe nei router intermedi (altrimenti come lo inoltri il traffico ? Fai un fllooding ?), meccanismo poi che non è molto sicuro.

ma a che router, almeno gli utenti di alice 20mega, creano e si registrano a questi gruppi di multicast? e questi gruppi possono essere creati dagli utenti stessi (troppo bello per essere vero)? o anche si potrebbe utilizzare uno di questi e riutilizzarlo, e se c'è una limitazione sulla sorgente dei dati, magari spoofare l'ip ( delirio di onnipotenza)?

[cionci]

Originariamente inviato da pisto

ma a che router, almeno gli utenti di alice 20mega, creano e si registrano a questi gruppi di multicast? e questi gruppi possono essere creati dagli utenti stessi (troppo bello per essere vero)? o anche si potrebbe utilizzare uno di questi e riutilizzarlo, e se c'è una limitazione sulla sorgente dei dati, magari spoofare l'ip ( delirio di onnipotenza)?

Purtroppo solitamente è il sorgente che ha particolari autorizzazione per registrare i gruppi. Dopo ci pensano i protocolli che scambiano le informazioni fra i router (non so se la rete telecom sia gestita in OSPF o un misto OSPF e BGP) a far arrivare la configurazione verso gli utenti.

[^TiGeRShArK^]

Originariamente inviato da 71104

ma non è che ad ogni frammento che invio allo stesso peer apro una nuova connessione eh

No però il tempo per creare molte connessioni è molto maggiore quando ne hai 10000 rispetto a quando ne hai 10.
Inoltre su 10000 connessioni sarà molto probabile che devi dedicare una parte della banda continuamente all'instaurazione di nuovi connessioni dato che saranno in molti ad abbandonare la connessione col tuo host ed altrettanti ad aggiungersi.

cioè se apro nuove connessioni aumentano i routers che stanno tra me e l'altro?
probabilmente volevi dire KeepAlive, non TimeToLive. il KeepAlive è un'opzione: se non la vuoi non la abiliti. tanto se una connessione è caduta silenziosamente te ne accorgerai non appena invierai nuovi dati.

Si, mi sono confuso col nome
il TTL non c'entra una mazza...
intendevo dire che se un pacchetto ci mette troppo viene considerato perso e viene richiesta la ritrasmissione andando ad occupare ulteriormente banda

non ho presente invece a cosa ti riferisci con la latenza: latenza di cosa?

Il tempo perchè i dati giungano a te dopo la prima richiesta.
Come ha spiegato cionci con l'esempio del ping prima.

nel senso che potrò finire prima di inviarli a tutti quanti? e grazie al cavolo... ma se tanto prima o poi quelle connessioni devono comunque avvenire perché stanno in coda e quei dati li devo comunque inviare... a sto punto diventa solo una questione di preferenza immotivata, o no?

Intanto hai uno spreco di banda per le motivazioni di cui sopra e inoltre è sicuramente necessario un meccanismo di gestione del download dei frammenti + sofisisticato e che occuperà inoltre + banda, perchè è irraggionevole aspettare di scaricare 9 mega e mezzo andando a 10 byte al secondo

stesso discorso di cui sopra: è un tempo biblico complessivo, ma per ciascuna connessione il tempo è sempre lo stesso.

No perchè l'overhead aumenta

ribadisco il discorso del multicast: se gli ISP lo ammettessero farebbero un favore a se stessi prima che a noi, perché il P2P sarebbe N volte più efficiente con N calcolato come una stima media del numero di peers che richiedono un file in una rete P2P (cento? mille? diecimila?). e il P2P è solo un esempio di ciò che migliorerebbe.

Il multicast è solo un modo particolare di instradamento dei pacchetti, ma le limitazioni di cui sopra resterebbero tutte.
Ciò non oglie che effettivamente l'utilizzo del multicast è molto + comodo in fase implementativa

[^TiGeRShArK^]

Originariamente inviato da 71104

si ma infatti ho fatto la domanda sbagliata
latenza è la latenza della connessione, e quella è l'unica cosa che so; non so tutto il resto
cos'è la varianza della latenza media (scusate l'ignoranza)?

Per varianza intendo che oltre al tempo medio necessario per ricevere un pacchetto aumenta anche la varianza dei tempi medi dei vari pacchetti.
Per tempo medio intendo il valore del massimo nella classica curva gaussiana utilizzata per definire la probablità che un pacchetto ti arrivi dopo un certo intervallo di tempo.
Per varianza si intende invece la pendenza della gaussiana.
Tanto + è stretta tanti + saranno i pacchetti che arriveranno in un tempo prossimo al tempo medio.
Invece all'aumentare delle coneessioni tale curva tenderà inevitabilmente ad allargarsi a sproposito.
In questo modo è quasi impossibile definire un timeout che vada bene per tutti i pacchetti tcp richiesti.

[cionci]

Originariamente inviato da ^TiGeRShArK^

In questo modo è quasi impossibile definire un timeout che vada bene per tutti i pacchetti tcp richiesti.

Il timeout del TCP tiene conto sia della varianza che della media pesata degli ultimi pacchetti e non esiste un timeout singolo, ma viene mantenuto per ogni connessione.

[71104]

Originariamente inviato da recoil

al momento che supporto manca?

semplicemente l'UDP Multicast via Internet non funziona: mandi un pacchetto ad un gruppo multicast con un TTL alto quanto ti pare e arriva solo nella LAN. provato di persona più e più volte per un progetto che ho fatto con un amico per un esame universitario.

non so come mai la cosa non funzioni, ma credo che semplicemente i routers blocchino i pacchetti UDP i cui indirizzi di destinazione siano nella gamma degli indirizzi multicast, tutto lì.

quando guardi contenuti con rossoalice (tanto per fare un esempio) stai usando un IP multicast, ho controllato una volta il traffico in uscita.
non so però se vengono bloccati ip multicast di servizi che non riguardano il provider, non ho mai provato

boh, in effetti può essere. in tal caso forse sarebbe anche possibile fregare gli ISP spoofando l'IP sorgente del pacchetto UDP uscente, ma avrebbero comunque modo di accorgersene perché l'ISP conosce tutta la topologia della rete; cioè, ha modo di accorgersi se da te è uscito un pacchetto in cui l'IP sorgente differisce dall'IP che ti hanno assegnato.

[71104]

Originariamente inviato da cionci

Mantenere un traffico multicast su internet è estremamente costoso,

costerebbe un logaritmo in base due di quanto gli costa adesso a causa dell'intensa attività P2P che esiste nel mondo. il multicast serve esattamente a quello: serve a ridurre il traffico tra i routers che devono recapitare un identico pacchetto ad N host diversi.

prima di tutto perché necessita di meccanismi di subscribe/unsubscribe nei router intermedi (altrimenti come lo inoltri il traffico ? Fai un fllooding ?), meccanismo poi che non è molto sicuro.

questo meccanismo esiste già ed è gestito dal protocollo IGMP: vedi setsockopt, opzioni IP(V6)_ADD_MEMBERSHIP e IP(V6)_DROP_MEMBERSHIP.

come mai non è molto sicuro?

[71104]

Originariamente inviato da pisto

io penso che uploadare ad una velocità troppo bassa renderebbe instabile la connessione stessa, cioè, talvolta quando mi capita di scaricare da server cinesi inculati chissaddove vado a mezzo kilobyte al secondo, e poi misteriosamente il download fallisce. non credo sia un problema del server o altro, ma del cmodo in cui il protocollo tcp gestisce la velocità del flusso, meccanismo che si basa se ho capito bene sui pacchetti che vengono persi nel tragitto per qualsiasi motivo e la cui mancanza viene recepita da tutt'e due gli host. sono sempre speculazioni cmq.

ma lo scenario che stiamo analizzando è diverso: si parla di una connessione aperta ma sulla quale non viaggia nulla, neanche pacchetti di keep-alive. una connessione del genere da che mondo è mondo dovrebbe rimanere aperta e perfettamente stabile.

l'esempio del server cinese invece è diverso: i pacchetti vengono inviati ma non arrivano per l'eccessiva distanza (magari ci sono più di 255 routers in mezzo, LOL ), e quindi tornano indietro dai routers dei pacchetti di errore che avvisano che i pacchetti vengono persi (questi pacchetti di errore se non erro sono gestiti dal protocollo ICMP e sono gli stessi che rendono possibile il traceroute), ed evidentemente uno stack TCP/IP quando vede che su quella connessione tornano indietro solamente errori la cassa.

[71104]

Originariamente inviato da pisto

e questi gruppi possono essere creati dagli utenti stessi (troppo bello per essere vero)?

i gruppi multicast non necessitano di essere creati: esistono virtualmente già tutti, serve solo che gli host facciano il join e che qualcuno mandi qualcosa. come ho scritto sopra il protocollo usato per gestire le membership ai gruppi multicast è IGMP.

o anche si potrebbe utilizzare uno di questi e riutilizzarlo, e se c'è una limitazione sulla sorgente dei dati, magari spoofare l'ip ( delirio di onnipotenza)?

ne ho parlato in un post precedente, spoofare l'IP si potrebbe anche visto che si tratta di UDP, ma gli ISP se ne accorgerebbero facilmente se è nei loro interessi ^^

[cionci]

Originariamente inviato da 71104

questo meccanismo esiste già ed è gestito dal protocollo IGMP: vedi setsockopt, opzioni IP(V6)_ADD_MEMBERSHIP e IP(V6)_DROP_MEMBERSHIP.

come mai non è molto sicuro?

Certo che esiste già...
Il problema è relativo a CHI ha il permesso di fare quelle richieste ai router. Non so se hai presente come funziona BGP...si fa di tutto per rendere la tabella di routing il più piccola possibile cercando di accettare il minimo numero di route necessarie facendo aggregazione, mentre con le opzioni sopra puoi rendere grande a piacimento la tabella di routing Tra l'altro le route multicast non sono nemmeno aggregabili perché non hanno una collocazione pseudo-geografica come gli indirizzi ip.
Ecco qual'è il costo, non certo il traffico (che poi sarebbe da vedere chi ha bisogno dello stesso segmento di file nello stesso istante...imho molto pochi).

[71104]

Originariamente inviato da ^TiGeRShArK^

No però il tempo per creare molte connessioni è molto maggiore quando ne hai 10000 rispetto a quando ne hai 10.

beh, ma perché scusa? mettiamo che ho N connessioni tutte aperte e tutte inattive (su nessuna viaggia niente); il tempo necessario a creare un'altra connessione aumenta? e perché mai? devo solo inviare un paio di pacchetti, i routers non sanno neanche che io ho N connessioni aperte (o meglio, non sono obbligati a saperlo).

Inoltre su 10000 connessioni sarà molto probabile che devi dedicare una parte della banda continuamente all'instaurazione di nuovi connessioni dato che saranno in molti ad abbandonare la connessione col tuo host ed altrettanti ad aggiungersi.

la banda necessaria all'instaurazione e alla chiusura di una connessione (ammesso che sia significativa, dal momento che si parla di pochi bytes contro i megabyte inviati dall'attività di P2P) è banda che useresti comunque anche col sistema delle code: se hai millemila peers in coda non significa che non li servirai mai, significa che li servirai dopo.

intendevo dire che se un pacchetto ci mette troppo viene considerato perso e viene richiesta la ritrasmissione andando ad occupare ulteriormente banda

il fatto che un host abbia registrato nella sua memoria che ci sono N connessioni attive con altrettanti peers non influenzerà di certo la velocità con cui la rete del provider riesce ad inviare un pacchetto da una parte all'altra.

Intanto hai uno spreco di banda per le motivazioni di cui sopra e inoltre è sicuramente necessario un meccanismo di gestione del download dei frammenti + sofisisticato e che occuperà inoltre + banda, perchè è irraggionevole aspettare di scaricare 9 mega e mezzo andando a 10 byte al secondo

ma mica ti arriva un pacchetto al secondo contenente solo 10 bytes eh...

No perchè l'overhead aumenta

l'overhead aumenta se aumenta la frammentazione, e non vedo perché la frammentazione debba aumentare.

Il multicast è solo un modo particolare di instradamento dei pacchetti, ma le limitazioni di cui sopra resterebbero tutte.

no perché gli ISP avrebbero molto meno traffico e le loro reti sarebbero più efficienti, diminuendo così la latenza di ciascuna connessione

Ciò non oglie che effettivamente l'utilizzo del multicast è molto + comodo in fase implementativa

io avrei detto il contrario: in fase implementativa il multicast per un programmatore è un beneficio quasi nullo (capirai, anziché fare un for che invia il pacchetto N volte ad N peers invio il pacchetto a tutti una volta sola).

[71104]

Originariamente inviato da cionci

(che poi sarebbe da vedere chi ha bisogno dello stesso segmento di file nello stesso istante...imho molto pochi).

questo non è vero: non sai quante volte scaricando un fil... ehm, un file .avi in DivX di grosse dimensioni ( ) da eMule ho notato che alla metà delle sorgenti mancava esattamente lo stesso pezzo

[cionci]

Originariamente inviato da 71104

questo non è vero: non sai quante volte scaricando un fil... ehm, un file .avi in DivX di grosse dimensioni ( ) da eMule ho notato che alla metà delle sorgenti mancava esattamente lo stesso pezzo

Questo è un altro discorso ed è dovuto al numero esiguo di fonti In particolare succede quando chi pubblica il file va offline prima che qualcuno abbia completato il download. Tutti quelli che sono online si scambiano parti di file fino ad arrivare allo stesso livello e quando chi pubblica torna online ovviamente è oberato di richieste e magari ci vuole tantissimo perché quella parte venga ridistribuita.

[^TiGeRShArK^]

Originariamente inviato da cionci

Il timeout del TCP tiene conto sia della varianza che della media pesata degli ultimi pacchetti e non esiste un timeout singolo, ma viene mantenuto per ogni connessione.

appunto, ma vista l'elevata varianza è molto + facile scambiare un pacchetto in ritardo per un pacchetto perso o viceversa aspettare troppo a richiedere la trasmissione per un pacchetto perso credendo che ancora debba arrivare

[71104]

Originariamente inviato da cionci

Questo è un altro discorso ed è dovuto al numero esiguo di fonti In particolare succede quando chi pubblica il file va offline prima che qualcuno abbia completato il download. Tutti quelli che sono online si scambiano parti di file fino ad arrivare allo stesso livello e quando chi pubblica torna online ovviamente è oberato di richieste e magari ci vuole tantissimo perché quella parte venga ridistribuita.

appunto: grazie al multicast sarebbe più facile ridistribuire quella parte perché distribuendola a più peers contemporaneamente ne aumenteresti la diffusione.

[cionci]

Originariamente inviato da 71104

appunto: grazie al multicast sarebbe più facile ridistribuire quella parte perché distribuendola a più peers contemporaneamente ne aumenteresti la diffusione.

Ma solo quella...quindi il multicast diventa adatto solo in caso di trasmissione da 1 a molti (non a caso è usato per il flusso video), ma da molti a molti i benefici imho diventano esegui.

[^TiGeRShArK^]

Originariamente inviato da 71104

beh, ma perché scusa? mettiamo che ho N connessioni tutte aperte e tutte inattive (su nessuna viaggia niente); il tempo necessario a creare un'altra connessione aumenta? e perché mai? devo solo inviare un paio di pacchetti, i routers non sanno neanche che io ho N connessioni aperte (o meglio, non sono obbligati a saperlo).

intanto quando scarichi con emule si presuppone che le connessioni non siano tutte in idle.. altrimenti a che ti servono?
e cmq come ho detto prima quello che dici tu sarebbe sicuramente vero per bande in upload molto maggiori di quelle italiane, ma se la banda è già satura per inviare dati il tempo per creare n connessioni aumenta.

la banda necessaria all'instaurazione e alla chiusura di una connessione (ammesso che sia significativa, dal momento che si parla di pochi bytes contro i megabyte inviati dall'attività di P2P) è banda che useresti comunque anche col sistema delle code: se hai millemila peers in coda non significa che non li servirai mai, significa che li servirai dopo.

si ma non sto rallentando l'upload dei file gestendo decine di migliaia di connessioni per volta..
già anche 10 byte per 10000 connessioni sono 100KB

il fatto che un host abbia registrato nella sua memoria che ci sono N connessioni attive con altrettanti peers non influenzerà di certo la velocità con cui la rete del provider riesce ad inviare un pacchetto da una parte all'altra.

non ho capito

ma mica ti arriva un pacchetto al secondo contenente solo 10 bytes eh...

No ti viene inviato un pacchetto appena trovi lo spazio per inserirlo sul canale.
Quindi l'attesa è molto + elevata e la mole di dati scambiati al secondo (o se preferisci al minuto o all'ora) per singola connessione è 1000 volte + bassa.

l'overhead aumenta se aumenta la frammentazione, e non vedo perché la frammentazione debba aumentare.

Perchè i frammenti DEVONO essere molto + piccoli dato che è irraggionevole aspettare 100 giorni per ricevere un singolo frammento da 9 MB e mezzo