View Full Version : hard-limit connessioni TCP
sapete se su Windows esiste un limite massimo imposto dal sistema operativo per il numero di connessioni TCP che l'host può ricevere? e per quelle che può effettuare verso l'esterno?
in caso di risposta affermativa volevo sapere come mai esiste questo limite e se e come è possibile eventualmente modificarlo. e per quanto riguarda altre piattaforme o implementazioni dello stack di rete? anche Linux ad esempio ha un limite?
^TiGeRShArK^
31-07-2007, 13:20
sapete se su Windows esiste un limite massimo imposto dal sistema operativo per il numero di connessioni TCP che l'host può ricevere? e per quelle che può effettuare verso l'esterno?
in caso di risposta affermativa volevo sapere come mai esiste questo limite e se e come è possibile eventualmente modificarlo. e per quanto riguarda altre piattaforme o implementazioni dello stack di rete? anche Linux ad esempio ha un limite?
bhè...
sicuramente il limite è 65536 ovunque :p
ilsensine
31-07-2007, 13:28
anche Linux ad esempio ha un limite?
C'è un limite per processo (file aperti, modificabile); credo anche un limite di connessioni in uscita dalla stessa interfaccia (~32k) in quanto per ogni connessione deve essere usata una coppia ip:porta di bind unica (e le porte dinamiche sono allocate da 32768 in poi su linux).
Non mi risultano limiti nelle connessioni in ingresso.
C'è un limite per processo (file aperti, modificabile); credo anche un limite di connessioni in uscita dalla stessa interfaccia (~32k) in quanto per ogni connessione deve essere usata una coppia ip:porta di bind unica (e le porte dinamiche sono allocate da 32768 in poi su linux).
Non mi risultano limiti nelle connessioni in ingresso.
giusto. nessun limite... il limite è collo di bottiglia.
L'algoritmo è mettere 0 la ricezione e la trasmissione e equilibrare sia la fase di ricezione che trasmissione o fare degli slot al massimo di tot come per gli sharing.
^TiGeRShArK^
31-07-2007, 15:58
giusto. nessun limite... il limite è collo di bottiglia.
L'algoritmo è mettere 0 la ricezione e la trasmissione e equilibrare sia la fase di ricezione che trasmissione o fare degli slot al massimo di tot come per gli sharing.
eh? :mbe:
C'è un limite per processo (file aperti, modificabile); credo anche un limite di connessioni in uscita dalla stessa interfaccia (~32k) in quanto per ogni connessione deve essere usata una coppia ip:porta di bind unica (e le porte dinamiche sono allocate da 32768 in poi su linux).
Non mi risultano limiti nelle connessioni in ingresso. tutti limiti di risorse insomma: se finiscono i numeri di porta i nuovi sockets non possono più essere bindati. stando così le cose immagino che la situazione sia analoga per Windows. il motivo per cui mi pongo tali interrogativi è che non capisco per quale assurdo motivo eMule implementa il suo frustrante sistema di code (frustrante per chi è in coda ovviamente): avrebbe avuto senso se il sistema avesse imposto un numero massimo di connessioni relativamente ridotto, perché in quel caso per il peer che ha il file sarebbe ragionevole una logica del tipo "se ho già accettato tutte le connessioni possibili e un nuovo peer si mette in coda prima di un altro, allora ha diritto lui per primo ad utilizzare una connessione verso di me non appena mi si libera".
ma non mi sembra questo il caso visto che il numero massimo di connessioni, come mi dite voi e come immaginavo io, sembra essere molto alto e limitato solo dalle risorse disponibili...
vorrei tanto capire cosa frullava nella testolina dell'autore di eMule :mbe:
voi che ne pensate?
OT: ilsensine, spiegami come hai fatto nel tuo post a scrivere "ip : porta" senza che i due punti e la p minuscola formassero la faccina --> :p
:D
OT: ilsensine, spiegami come hai fatto nel tuo post a scrivere "ip : porta" senza che i due punti e la p minuscola formassero la faccina --> :p
:D
Niubbone :sofico: Basta disattivare le faccine da sotto al form in cui scrivi il messaggio ;)
Comunque che io sappia Windows XP ha un hard limit di 50 connessioni contemporanee. Infatti a giro si trovano patch per tcpip.sys per superare tale limite.
Riguardo al limite del numero delle porte...in teoria anche quando finiscono le porte utente si potrebbe utilizzare una porta utente già usata perché la connessione TCP può essere indicizzata tramite la coppia di endpoint (ipclient : porta - ipserver : porta), se poi questo non viene usato non lo so.
^TiGeRShArK^
01-08-2007, 08:29
Niubbone :sofico: Basta disattivare le faccine da sotto al form in cui scrivi il messaggio ;)
Comunque che io sappia Windows XP ha un hard limit di 50 connessioni contemporanee. Infatti a giro si trovano patch per tcpip.sys per superare tale limite.
Riguardo al limite del numero delle porte...in teoria anche quando finiscono le porte utente si potrebbe utilizzare una porta utente già usata perché la connessione TCP può essere indicizzata tramite la coppia di endpoint (ipclient : porta - ipserver : porta), se poi questo non viene usato non lo so.
ehmmm..
mi sa di no :p
ogni tanto con un netstat -a -n vedo ben + di 50 connessioni aperte :asd:
Cmq il sistema di code di meule è ovvio secondo me :mbe:
Se tutti si collegassero contemporaneamente si avrebbe un overhead assurdo e inoltre la banda utile sarebbe troppo bassa per scaricare frammenti di dimensione significativa.
Infatti, se noti, il mulo ha un sistema "doppio".
Utilizza quasi tutta la banda dividendola tra un numero limitato di connessioni, e quello che resta, anzikè non usarlo lo assegna ad altri, ma con velocità bassissime, che di solito sonoo usate per il meccanismo di ICH e per cose del genere.
50 connessioni TCP...non so se sono 50 TCP e 50 UDP.
Comunque ora cerco il sito della patch, almeno potete vedere meglio.
Comunque che io sappia Windows XP ha un hard limit di 50 connessioni contemporanee. Infatti a giro si trovano patch per tcpip.sys per superare tale limite. e quale sarebbe la motivazione di questo limite...? :-|
ma si tratta di connessioni in ingresso o in uscita? adesso mi sa che provo ad aprire 50 tab su Firefox :fagiano:
Riguardo al limite del numero delle porte...in teoria anche quando finiscono le porte utente si potrebbe utilizzare una porta utente già usata perché la connessione TCP può essere indicizzata tramite la coppia di endpoint (ipclient : porta - ipserver : porta), se poi questo non viene usato non lo so. anche questo è vero... :mbe:
ma si tratta di connessioni in ingresso o in uscita? adesso mi sa che provo ad aprire 50 tab su Firefox :fagiano:
Questo non permette di raggiungere il limite...le connessioni di Firefox sono getite a gruppi e comunque limitate dal browser stesso.
Comunque ora cerco...
Se tutti si collegassero contemporaneamente si avrebbe un overhead assurdo e inoltre la banda utile sarebbe troppo bassa per scaricare frammenti di dimensione significativa. overhead di che cosa scusa? :wtf:
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 :D
semmai quei 4 KB riuscirà ad inviarli in un tempo più lungo a causa del fatto che contemporaneamente ne deve inviare altrettanti a parecchia altra gente. ma se gli ISP sono così idioti da non capire che se solo supportassero il multicast via Internet la banda in uso diminuirebbe a vantaggio loro... :muro:
comunque ancora non capisco il perché delle code: per quale motivo chi si connette prima avrebbe diritto a ricevere per primo tutti i pacchetti? secondo me è assurdo, infatti quando usavo DC++ riuscivo mediamente a scaricare molto di più...
Infatti, se noti, il mulo ha un sistema "doppio".
Utilizza quasi tutta la banda dividendola tra un numero limitato di connessioni, e quello che resta, anzikè non usarlo lo assegna ad altri, ma con velocità bassissime, che di solito sonoo usate per il meccanismo di ICH e per cose del genere. cos'è il meccanismo di ICH? :p
@cionci: suppongo che questo limite delle 50 connessioni sia diverso per le edizioni server di Windows, perché un server che può accettare solo 50 connessioni mi fa un po' ridere :D
Allora la cosa è diversa. C'è un limite al numero di connessione TCP half-opened.
http://www.lvllord.de/
Cosa di cui emule fa uso massivo...
Allora la cosa è diversa. C'è un limite al numero di connessione TCP half-opened. AAAA ECCO.
http://www.lvllord.de/
Cosa di cui emule fa uso massivo... per caso sai il motivo?
ps. comunque si dice massiccio, ti sarai confuso con l'inglese massive :D
Addirittura sono 10 le connessioni half-open senza patch: http://www.lvllord.de/?lang=en&url=4226patch/faq
Le connessioni half-opened sono quelle che non hanno ancora completato il terzo ramo del three-way handshake...quindi tutte le connessioni TCP passano dallo stato half-opened.
In pratica mi sembra di capire che si applica solo alle connessioni in ingresso e lo stato è quello in cui si è ricevuto syn, si è inviato syn+ack, ma non si è ancora ricevuto l'ack.
E' ovvio che emule ne faccia largo uso perché sono spesso tanti gli utenti che si connettono al nostro emule. Quindi più di 10 connessioni contemporanee il so non le può gestire (senza patch).
ps. comunque si dice massiccio, ti sarai confuso con l'inglese massive :D
:uh:
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.
:read:
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).
ilsensine
01-08-2007, 11:29
E' ovvio che emule ne faccia largo uso perché sono spesso tanti gli utenti che si connettono al nostro emule.
Come fa emule a "gestire" una cosa completamente nelle mani del s/o? :mbe:
Come fa emule a "gestire" una cosa completamente nelle mani del s/o? :mbe:
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.
:uh:
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.
:read: chiedo venia, non ero a conoscenza del punto 1 :|
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 :asd: ).
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.
infatti è un limite ragionevolissimo, anzi non capisco a questo punto a che cavolo serva la patch (a rendersi vulnerabili :asd: ).
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.
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 :D
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 :D
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
01-08-2007, 12:01
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?
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
01-08-2007, 12:23
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?
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^
01-08-2007, 14:50
overhead di che cosa scusa? :wtf:
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 :D
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? :p
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 :D) di byte corrotte :p
In quel modo può efficacemente sfruttare bande anche di poche decine di byte al secondo.
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 :D) di byte corrotte :p non dalla stessa fonte spero :asd:
^TiGeRShArK^
01-08-2007, 15:46
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 :asd:
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 :p
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.
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 :fagiano:
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? :fagiano:
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.
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.
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 :D
latenza è la latenza della connessione, e quella è l'unica cosa che so; non so tutto il resto :p
cos'è la varianza della latenza media (scusate l'ignoranza)?
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
02-08-2007, 09:43
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.
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...
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...
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.
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.
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 (:fagiano: delirio di onnipotenza)?
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 (:fagiano: 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^
02-08-2007, 12:42
ma non è che ad ogni frammento che invio allo stesso peer apro una nuova connessione eh :fagiano:
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? :fagiano:
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 :p
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 :p
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 :fagiano:
stesso discorso di cui sopra: è un tempo biblico complessivo, ma per ciascuna connessione il tempo è sempre lo stesso.
No perchè l'overhead aumenta :p
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^
02-08-2007, 12:45
si ma infatti ho fatto la domanda sbagliata :D
latenza è la latenza della connessione, e quella è l'unica cosa che so; non so tutto il resto :p
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.
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.
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.
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? :wtf:
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 :D), 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.
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 (:fagiano: delirio di onnipotenza)? :D
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 ^^
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? :wtf:
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).
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 :p 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 :fagiano: ma mica ti arriva un pacchetto al secondo contenente solo 10 bytes eh...
No perchè l'overhead aumenta :p 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 :D
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).
(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 ( :asd: ) da eMule ho notato che alla metà delle sorgenti mancava esattamente lo stesso pezzo :D
questo non è vero: non sai quante volte scaricando un fil... ehm, un file .avi in DivX di grosse dimensioni ( :asd: ) da eMule ho notato che alla metà delle sorgenti mancava esattamente lo stesso pezzo :D
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^
02-08-2007, 15:43
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 :p
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.
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^
02-08-2007, 15:54
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? :p
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 :p
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 :fagiano:
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 :p
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.