hard-limit connessioni TCP

[cionci]

Originariamente inviato da ilsensine

Come fa emule a "gestire" una cosa completamente nelle mani del s/o?

Infatti non la gestisce, ho scritto che la gestisce ? Emule esce limitato dal numero massimo di connessioni contemporanee half-opened che il SO gestisce.
Come lui anche tutti gli altri programmi p2p, ovviamente tranne quelli che viaggiano esclusivamente su UDP.

Nel link sopra c'è anche scritto come verificare se il limite entra o meno in funzione.

[71104]

Originariamente inviato da cionci

Lemma massivo
Sillabazione/Fonetica [mas-sì-vo]
Etimologia Dal fr. massif, deriv. di masse 'massa'
Definizione agg.
1 massiccio, in gran quantità: immigrazione massiva; dose massiva
2 (fis.) che si riferisce alla massa; massico
§ massivamente avv.

chiedo venia, non ero a conoscenza del punto 1 :|

[71104]

Originariamente inviato da cionci

Per quanto riguarda il motivo di questo limite, credo che l'abbiano introdotto in SP2 per proteggersi dal syn flood (anche 2003 Server ce l'ha).

infatti è un limite ragionevolissimo, anzi non capisco a questo punto a che cavolo serva la patch (a rendersi vulnerabili ).

di conseguenza il sistema delle code di eMule non c'entra niente con questo hard-limit, e io ancora non ho capito per quale assurdo motivo della terra eMule debba preferire i clients connessi per primi, e cosa frullasse nella testolina dell'autore.

[cionci]

Originariamente inviato da 71104

infatti è un limite ragionevolissimo, anzi non capisco a questo punto a che cavolo serva la patch (a rendersi vulnerabili ).

50 può essere ragionevole...certo chi ti fa un syn flood spoofato non ti apre 10 connessioni e basta. Senza contare che spesso sono i router ad avere una protezione per il syn flood incorporata che rende inutile quella del SO.

[71104]

Originariamente inviato da cionci

50 può essere ragionevole...certo chi ti fa un syn flood spoofato non ti apre 10 connessioni e basta. Senza contare che spesso sono i router ad avere una protezione per il syn flood incorporata che rende inutile quella del SO.

e a maggior ragione rende inutile una patch per aumentare il numero di connessioni half-open, a meno che chi ti fa il flood non è uno nella LAN

[cionci]

Originariamente inviato da 71104

e a maggior ragione rende inutile una patch per aumentare il numero di connessioni half-open, a meno che chi ti fa il flood non è uno nella LAN

Solitamente il limite dei router è maggiore di 10 Molto maggiore oserei dire.
Comunque prova a vedere dal link quante volte l'errore ti appare nel log ed almeno ti togli ogni dubbio
Se nell'uso normale appare troppe volte allora il limite è troppo basso...

[ilsensine]

Originariamente inviato da cionci

Infatti non la gestisce, ho scritto che la gestisce ? Emule esce limitato dal numero massimo di connessioni contemporanee half-opened che il SO gestisce.

Come fa a lasciare delle connessioni "half-open"? Smette di eseguire la accept?

[cionci]

Originariamente inviato da ilsensine

Come fa a lasciare delle connessioni "half-open"? Smette di eseguire la accept?

Non è che le lascia...ma c'è un intervallo di tempo in cui la connessione rimane half-opened. Se in questo intervallo arrivano altre 10 connessioni nello stesso stato il sistema operativo non accetta più syn in ingresso o meglio non invia più syn + ack e scarta i syn.

L'intervallo di tempo in questione è quello fra l'invio di syn + ack e la ricezione di ack + eventuali dati. E' quindi un RTT. In connessioni P2P è in genere molto più grande delle connessioni fra un client e un provider (questo perché entrambi gli endpoint si trovano spesso al di là di una moltitudine di router che non fanno altro che aggiungere latenza). IMHO può arrivare anche oltre il secondo e mezzo.
Quindi 10 connessioni half-opened ci vuole pochissimo a raggiungerle.

[ilsensine]

Originariamente inviato da cionci

Non è che le lascia...ma c'è un intervallo di tempo in cui la connessione rimane half-opened. Se in questo intervallo arrivano altre 10 connessioni nello stesso stato il sistema operativo non accetta più syn in ingresso o meglio non invia più syn + ack e scarta i syn.

Ho capito cosa intendi...ma questo presuppone un tasso di richieste di connessione veramente elevato; col p2p accadono queste cose?

[cionci]

Originariamente inviato da ilsensine

col p2p accadono queste cose?

Soprattutto in certi istanti...come ad esempio all'inizio alla connessione alla rete kad ed alla pubblicazione della lista dei file...
Ma immaginati su un server con richieste continue (anche 2003 server soffre di questa limitazione), sarebbe ancora più frequente.

[^TiGeRShArK^]

Originariamente inviato da 71104

overhead di che cosa scusa?
e poi il discorso non ha molto senso: se il programma vuole inviare 4 KB mica invia 1 byte solo... il frammento che invia non può mica diminuire di dimensioni a causa del numero di connessioni

Bhè...

gestendo 10000 connessioni avrai una percentuale MOLTO + elevata della tua banda che è usata per l'overhead del TCP rispetto ad avere 10 connessioni....
E cmq invierai i dati ad una velocità insufficiente perchè sia efficacemente gestita dal mulo.
Per far si che anche frammenti di dati così piccoli siano utili bisognerebbe ancora una volta aumentare l'overhead per usare politiche di gestione dei fargments + raffinate.

cos'è il meccanismo di ICH?

Intelligent Corruption Handling è il meccanismo utilizzato da EMULE per riscaricare i dati corrotti.
In pratica anzikè riscaricare un intero frammento da 9 mega e rotti scarica solo le poche centinaia (si spera ) di byte corrotte
In quel modo può efficacemente sfruttare bande anche di poche decine di byte al secondo.

[71104]

Originariamente inviato da ^TiGeRShArK^

Bhè...

gestendo 10000 connessioni avrai una percentuale MOLTO + elevata della tua banda che è usata per l'overhead del TCP rispetto ad avere 10 connessioni....

perché mai il numero di connessioni dovrebbe influenzare la frammentazione del flusso di dati che scorre lungo la singola connessione TCP? cioè se io chiamo una send e gli passo 4 KB di dati, stai dicendo che questa può ritornarmi di più o di meno a seconda del numero di connessioni stabilite...

E cmq invierai i dati ad una velocità insufficiente perchè sia efficacemente gestita dal mulo.

io invio 4 KB di dati; i successivi 4 KB li posso inviare dopo pochi attimi se ho poche connessioni o dopo svariati secondi se ho tante connessioni. come mai nel secondo caso eMule funzionerebbe peggio se non avesse il sistema delle code?

Intelligent Corruption Handling è il meccanismo utilizzato da EMULE per riscaricare i dati corrotti.
In pratica anzikè riscaricare un intero frammento da 9 mega e rotti scarica solo le poche centinaia (si spera ) di byte corrotte

non dalla stessa fonte spero

[^TiGeRShArK^]

Originariamente inviato da 71104

perché mai il numero di connessioni dovrebbe influenzare la frammentazione del flusso di dati che scorre lungo la singola connessione TCP? cioè se io chiamo una send e gli passo 4 KB di dati, stai dicendo che questa può ritornarmi di più o di meno a seconda del numero di connessioni stabilite...

io invio 4 KB di dati; i successivi 4 KB li posso inviare dopo pochi attimi se ho poche connessioni o dopo svariati secondi se ho tante connessioni. come mai nel secondo caso eMule funzionerebbe peggio se non avesse il sistema delle code?

non dalla stessa fonte spero

Allora per quanto riguarda l'overhead scambiare 100KB di dati con 10 connessioni TCP è + veloce che scambiarlo con 10000 connessioni per via dell'handshaking necessario per instaurarle.
Inoltre,a connessioni già stabilite, quando hai troppe connessioni avrai inevitabilmente maggiori problemi di TimeToLive e di aumento spropositato della varianza della latenza media.
Con un numero minore di connessioni potrai inviare i dati + efficacemente.
Ovviamente tutto questo è relativo alla banda disponibile.
Se mettiamo caso tu avessi 10 MBit in upload allora l'overhead dato da 10000 connessioni TCP sarebbe trascurabile, ma così non è con i 256kbit delle connessioni medie italiane
Emule funziona al meglio quando un frammento viene interamente trasferito.
questi frammenti hanno una dimensione di 9,5 mb circa (a meno di file di dimensioni + piccole in cui la dimensione dei frammenti sarà ovviamente minore).
Quindi inviare 9 mega e mezzo con 32kb/s di upload diviso tra 10000 connessioni è praticamente un tempo biblico.
Ovviamente è sempre possibile inviare meno dati, ma, come dicevo prima, è meno efficiente.

[71104]

Originariamente inviato da ^TiGeRShArK^

Allora per quanto riguarda l'overhead scambiare 100KB di dati con 10 connessioni TCP è + veloce che scambiarlo con 10000 connessioni per via dell'handshaking necessario per instaurarle.

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

Inoltre,a connessioni già stabilite, quando hai troppe connessioni avrai inevitabilmente maggiori problemi di TimeToLive e di aumento spropositato della varianza della latenza media.

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.

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

Con un numero minore di connessioni potrai inviare i dati + efficacemente.

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?

Quindi inviare 9 mega e mezzo con 32kb/s di upload diviso tra 10000 connessioni è praticamente un tempo biblico.

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

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.

[cionci]

Originariamente inviato da 71104

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

La latenza dei router che ti permettono di arrivare su internet. Prova a pingare mentre hai emule aperto a scaricare.

[71104]

Originariamente inviato da cionci

La latenza dei router che ti permettono di arrivare su internet. Prova a pingare mentre hai emule aperto a scaricare.

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)?

[okay]

purtroppo sono passato a infostrada e pare che non posso postare qui sul forum quando mi pare è un problema di infostrada e dsn... purtroppo!!!!
Non riesco ad aprire neanche MSN... porca pu...na!!
Cmq dopo TiGeRShArK avrei voluto postare questo: Sto copiando e incollando prima o poi riuscirò a postare i miei messaggi... sò messo male con info strada. Spero che sia un problema di doppino oppure dovrò cambiare modem!
Oppure non sò proprio cosa fare intanto o aperto un ticket su libero!

TCP:

Il valore di default è 500 massimo di connessioni, poi dipende. C'è scritto nel regfile (vallo a vedere).

Tutto è gestito dall'OS. Su XP, per esempio si può > questo valore fino pure a 80.000, ma è l'OS che gestisce il limite.

Se in un OS hai di default 500 connessioni in entrata e uscita tramite programma (c, vb ecc ecc) puoi aprire tutte le porte/a per la comunicazione.

Ora per problemi di flusso, instradamento dei pacchetti, smistamento dei vari nodi e router, lentezza nella rete ecc ecc. succede che le porte dell'OS arrivate a 500 fà fatica a gestire i flussi. Gestisce i flussi (asincroni) limitando in modo random le porte connesse con flussi + veloci e abbassanado i flussi di ricezione ad ltre porte. Questo poi dipende dalla "finestra" che per default è configurata dalll'OS a "2500" come limite di finestra.

In sostanza i famosi colli di bottiglia sono:
per il TCP (gestione automatica del flusso). Congestione anche a 200 connessioni aperte dipende dalla rete e come arrivano i dati.
UDP (non automatica) ma sviluppata da codice.

Il collo di bottiglia è dato dal limite dell'OS delle connessioni che può aprire (gestione solo dell'OS) + velocità della rete, rallentamenti o perdita di pacchetti.

Ho riletto quello che ho scritto sopra è non riesco a capirlo molto bene neanche io...

Cmq in 2 righe:
gestione flussi OS + rallentamento instradamento dati determina la velocità di ricezione dati.
Quindi a + connessioni aperte gli ms (es. 200 ms) vanno divisi per i connessi.
1 connessione 200 ms
2 connessioni (asincrona) 60 (1 client connesso) 40 (2 client connesso)
3 connessioni (asincroa) 33( 1 client connesso) 43 (2 client connesso) 24 (3 client connesso)

il limite per le connessioni non c'è se non fino a congestione e blocco del pc.







Edit OT:
Incredibile: ho scaricato un programmino Dr. TCP
Premetto che con adsl telecom funzionava tutto bene mentre con infostrada non riuscivo a postare su questo forum ora mettendo l'MTU non a 0 come di default ma a 1492 FUNZIONA tutto!!!!!!!

Edit:
download Dr. TCP (per avere le modifiche bisogna riavviare il pc)
http://www.speedguide.net/downloads.php
guida all'uso:
http://www.disteland.com/trucchi/drtcp/
il problema (il mio in particolare... era) il modem manta usb che con libero deve avere l'MTU impostato a 1492... tutto quì... incredibile.

Anche se non si capisce bene quello che scrivo è giusto ciò che ho postato riguardo il post e cioè che il limite è gestito dal OS ecc ecc.

Ho realizzato per un motore per videogame il motore del sound (che non centra nulla con il post) e il gioco in rete Multiplayer in 2 versioni funzionanti una in directplay e una con winsock (in quanto directplay e deprecata da microsoft)... quindi anche se non mi spiego bene il problema l'ho affrontai e lo conosco molto ma molto bene.

[tomminno]

Originariamente inviato da cionci

La latenza dei router che ti permettono di arrivare su internet. Prova a pingare mentre hai emule aperto a scaricare.

Qui entrano in gioco le limitazioni imposte dal provider in caso di transito di pacchetti eDonkey.
I nuovi router Cisco vanno addirittura ad analizzare il contenuto dei pacchetti per capire cosa sta transitando.

[recoil]

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.

al momento che supporto manca?
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

il limite a 10 connessione mezze aperte è stato messo (cos' dicono loro) per evitare la veloce diffusione di worms. rallenta emule, infatti appena lo apri può raggiungere anche le 100-200 connessioni simultanee.
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.

P.S.
qualcuno ha capito che dice okay??
e poi...

Originariamente inviato da okay

Tutto è gestito dall'OS. Su XP, per esempio si può > questo valore fino pure a 80.000, ma è l'OS che gestisce il limite.

beh, 2^16=65535, 65535<80000 di questo siamo sicuri...