Ne sparo una ... TCP/IP [Archivio] - Hardware Upgrade Forum

marwi

05-03-2005, 13:41

Ciao a tutti

premetto che di queste cose non capisco un tubo:D :mc:

ho riflettuto un pò sul controllo errori dei pacchetti... che da come ho capito sono "organizzati" dal TCP/IP... ICMP etc

il settaggio in fast non è altro che l'eliminazione (o parziale) del controllo errori che sono legati ai pacchetti, con il risultato che questi sono molto più piccoli e avremo , quindi, una latenza minore.

questo però avviene anche dal nostro computer? il driver standard TCP/IP che tutti noi abbiamo installato compila i pacchetti con l'aiuto del ICMP, quindi con le istruzioni sugli errori, con il risultato di avere pacchetti più grandi.

Non c'è modo di togliere l'ICMP? di disabilitarlo... o cmq non esiste un driver TCP/IP modificato con una diversa gestione del controllo errori?

in questo modo (se questo sia reale.. e possibile:D ) possiamo settarci da soli il Fast..

Per questo ho scritto che ne sparo una... perchè non so minimamente se quello che ho scritto è possibile o reale... è solo frutto della mia immaginazione in base alle mie scarsissime conoscenze in materia.

Spero di non creare casini, vediamo se riusciamo ad elaborare qualcosa

grazie per l'attenzione!

:)

Vecchia Spugna

05-03-2005, 13:53

Io sono + ignorante di te(e ce ne vuole:D )
Però secondo me se fosse possibile qualcuno l'avrebbe fatto.
Tuttavia alle mie enormi orecchie :p non è mai giunta tale notizia, quindi ne deduco per modus ponens (scusate il riferimentoi, ma sn fresco di esame di logica) che nessuno l'ha mai fatto, quindi deduco a sua volta che non sia possibile :sofico:

Ciauuuuuu

marwi

05-03-2005, 15:59

si ma io voglio il parere di uno smanettone!

uno che di TCP/IP ne capisce e non poco....
io di driver modificati ne ho sentito parlare.. ma... non riesco a trovare nulla .

Furbastro

05-03-2005, 17:35

Il settaggio in fast che ti fanno in centrale permette al router di trattare diversamente i pacchetti.In questo modo il tempo di transito diminuisce.Guarda che se riduci di molto la dimensione dei pacchetti agendo sulla MTU rischi di ottenere l'opposto di quello che vuoi fare, perche' aumenti a dismisura l'overhead con il risultato che mandi piu' header che dati.Ci sarebbe molto da dire a riguardo.In sintesi, cmq, e' che se disabiliti l'ICMP non riesci ad ottenere l'aumento di velocita' di transito dei pacchetti che tu auspichi di avere.Cmq l'ICMP non fa il controllo di errore, ma gestisce altri servizi come l'"echo request/replay" aka "ping".

TheBenchmarkSHuB

05-03-2005, 17:47

Tale modifica nel caso venise aplicata sara supervisionata
(stane certo) dal HOST (ISP) che sicuramente non gradirebbe lo scherzetto :nonsifa:
quelli il trasporto pachetti ip via TCP da e a lo controllano eccome:)
secondo te come farebbe la autorita competente a tracciare dopo atenta analise gli utenti che secondo loro utilizano la rete in modo illegale ? sono i pachetti trasportati via tcp per non dire il tuo indirizzo IP che li portano da te e comunque tracce del tuo passaggio si vedra prima o poi, quindi riguardo sempre al tcp, almeno che tu non hai un tuo propio ISP dislocato in mezzo al deserto e ti colleghi da un portatile con una scheda tipo modem moolto moded e particolare prendendo in prestito magari il segale/line da qualcun altro e ritrasmetendo il tutto poi (via tcp) come se fosse la tua bandwidth legale :eek: bhè e communque latenza piu basa (ping) grazie al mode set FAST non so a quanto potrebbe giovare nei casi qui citati, semai una linea alla velocita della luce ...
la tua idea se in disacordo con i "parametri" pre impostati dai fornitori internet (se loro dicono nel contrato fast... è fastaltrimenti no e non importa se modifichi "solo" dal lato utente certi parametri (tipo controllo errore) perchè potrebbe distabilizare qualche parametro anche dal lato ISP se aplicata senza il loro consenso e supervisione oltre che assistenza tecnica specializata) , nel caso venise violata quest ultima, non farebbe altro che ofrire un ulteriore lavoro ale forze dell ordine della sezione telematica e a parer mio questa cosa sarebbe molto peggio della pirateria internet di oggi :ops: ci si adentra nel furto vero e propio di bandwidth (banda) o perlomeno del diritto ai fornitori di acesso alla rete del aplicare tale modifiche su latenza ect..
chissa magari qualche idea verra a microsoft visto che a fine 2006 ci trasformera il pc in una specie di cassaforte a prova di manomissione quasi hardware e volendo la tua idea si scontra perfettamente con quella di microsoft e degli ISP.
è una modifica illegale (solo teoria per ora) ma lo è.
argomento vasto e da aprofondire certo:rolleyes:
ps: la idea è interessante se almeno fosse nel limite della legge :) e con il consenso di chi ci permette di viaggiare sulla loro linea.
penso che certi test prove teorie-pratiche potrebbero essere fatte in una LAN ovviamente senza spargere tracce di modifiche lato utente in un luogo publico come ARPHANET che ha sempre avuto e non a caso le sue regole ed impostazione gia studiate dai suoi fondatori creatori ect...
*vedi ipv6 quanto ci mette a diventare il sostituto del 4:muro:

edivad82

05-03-2005, 21:29

per farla semplice semplice...il tcp non c'entra una mazza in quanto il tutto viene eseguito su frame ATM...

fastpath è un percorso parallelo all'interleaved...

edivad82

05-03-2005, 21:34

Originariamente inviato da marwi
Ciao a tutti

premetto che di queste cose non capisco un tubo:D :mc:

ho riflettuto un pò sul controllo errori dei pacchetti... che da come ho capito sono "organizzati" dal TCP/IP... ICMP etc

il settaggio in fast non è altro che l'eliminazione (o parziale) del controllo errori che sono legati ai pacchetti, con il risultato che questi sono molto più piccoli e avremo , quindi, una latenza minore.

questo però avviene anche dal nostro computer? il driver standard TCP/IP che tutti noi abbiamo installato compila i pacchetti con l'aiuto del ICMP, quindi con le istruzioni sugli errori, con il risultato di avere pacchetti più grandi.

Non c'è modo di togliere l'ICMP? di disabilitarlo... o cmq non esiste un driver TCP/IP modificato con una diversa gestione del controllo errori?

in questo modo (se questo sia reale.. e possibile:D ) possiamo settarci da soli il Fast..

Per questo ho scritto che ne sparo una... perchè non so minimamente se quello che ho scritto è possibile o reale... è solo frutto della mia immaginazione in base alle mie scarsissime conoscenze in materia.

Spero di non creare casini, vediamo se riusciamo ad elaborare qualcosa

grazie per l'attenzione!

:)

resetta la mente :D non c'entra una pippa :D

edivad82

05-03-2005, 21:49

Originariamente inviato da TheBenchmarkSHuB
Tale modifica nel caso venise aplicata sara supervisionata
(stane certo) dal HOST (ISP) che sicuramente non gradirebbe lo scherzetto :nonsifa:
quelli il trasporto pachetti ip via TCP da e a lo controllano eccome:)
secondo te come farebbe la autorita competente a tracciare dopo atenta analise gli utenti che secondo loro utilizano la rete in modo illegale ? sono i pachetti trasportati via tcp per non dire il tuo indirizzo IP che li portano da te e comunque tracce del tuo passaggio si vedra prima o poi, quindi riguardo sempre al tcp, almeno che tu non hai un tuo propio ISP dislocato in mezzo al deserto e ti colleghi da un portatile con una scheda tipo modem moolto moded e particolare prendendo in prestito magari il segale/line da qualcun altro e ritrasmetendo il tutto poi (via tcp) come se fosse la tua bandwidth legale :eek: bhè e communque latenza piu basa (ping) grazie al mode set FAST non so a quanto potrebbe giovare nei casi qui citati, semai una linea alla velocita della luce ...
la tua idea se in disacordo con i "parametri" pre impostati dai fornitori internet (se loro dicono nel contrato fast... è fastaltrimenti no e non importa se modifichi "solo" dal lato utente certi parametri (tipo controllo errore) perchè potrebbe distabilizare qualche parametro anche dal lato ISP se aplicata senza il loro consenso e supervisione oltre che assistenza tecnica specializata) , nel caso venise violata quest ultima, non farebbe altro che ofrire un ulteriore lavoro ale forze dell ordine della sezione telematica e a parer mio questa cosa sarebbe molto peggio della pirateria internet di oggi :ops: ci si adentra nel furto vero e propio di bandwidth (banda) o perlomeno del diritto ai fornitori di acesso alla rete del aplicare tale modifiche su latenza ect..
chissa magari qualche idea verra a microsoft visto che a fine 2006 ci trasformera il pc in una specie di cassaforte a prova di manomissione quasi hardware e volendo la tua idea si scontra perfettamente con quella di microsoft e degli ISP.
è una modifica illegale (solo teoria per ora) ma lo è.
argomento vasto e da aprofondire certo:rolleyes:
ps: la idea è interessante se almeno fosse nel limite della legge :) e con il consenso di chi ci permette di viaggiare sulla loro linea.
penso che certi test prove teorie-pratiche potrebbero essere fatte in una LAN ovviamente senza spargere tracce di modifiche lato utente in un luogo publico come ARPHANET che ha sempre avuto e non a caso le sue regole ed impostazione gia studiate dai suoi fondatori creatori ect...
*vedi ipv6 quanto ci mette a diventare il sostituto del 4:muro:

poi me la spieghi, eh? :D

TheBenchmarkSHuB

06-03-2005, 00:10

di la tua;)
marwi te ne sara grato
Originariamente inviato da edivad82
poi me la spieghi, eh? :D

TheBenchmarkSHuB

06-03-2005, 00:14

percorso parallelo e oltre latenze migliori la velocita non varia:D
molti credono il contrario
Originariamente inviato da edivad82
per farla semplice semplice...il tcp non c'entra una mazza in quanto il tutto viene eseguito su frame ATM...

fastpath è un percorso parallelo all'interleaved...

Stargatto

06-03-2005, 00:14

bench leggero ot...
mi hanno upgradato :D

TheBenchmarkSHuB

06-03-2005, 00:20

non farci mancare un bello screenshot:cool:
Auguri:sofico: Originariamente inviato da Stargatto
bench leggero ot...
mi hanno upgradato :D

edivad82

06-03-2005, 01:05

Originariamente inviato da TheBenchmarkSHuB
di la tua;)
marwi te ne sara grato
più che altro non ho capito che ha scritto :D

marwi

06-03-2005, 02:24

grazie a tutti ragazzi per l'interessamento!!!

l'idea è stramba e se non si capisce quello che ho scritto è per il semplice fatto che ho pochissima conoscenza in materia..

la risposta che mi ha dato TheBenchmarkSHuB è stata chiarissima e ,strano ma vero, l'ho capita.

io credevo che la modifica del tcp/ip fosse una cosa più semplice e solo a lato client.. ma non credevo (non avevo minimamente pensato) che effettivamente il "Mio" fastpath avrebbe raggiunto il mio provider... e ovviamente non ne sarebbe passato inosservato... anzi...

credevo che la cosa fosse stata più leggera e che se io decidevo di togliere il controllo errori.. mi sarei preso da solo le mie responsabilità, restando, quindi, legale sotto tutti i punti di vista!

porcaccia.. torno sempre al solito discorso.... ci vuole che alice dia la possibilità all'utente di decidere se attivare o no la linea in fast path specificando che quest'ultimo si sarebbe preso ogni responsabilità sui probabili errori riscontrabili..

per me il fast path è un discorso di vita o di morte...

comunque se qualcuno sa come approfondire ulteriormente l'argomento o ha qualche brillante idea è ben accolto!

grazie nuovamente a tutti

Furbastro

06-03-2005, 09:57

Originariamente inviato da marwi
grazie a tutti ragazzi per l'interessamento!!!

l'idea è stramba e se non si capisce quello che ho scritto è per il semplice fatto che ho pochissima conoscenza in materia..

la risposta che mi ha dato TheBenchmarkSHuB è stata chiarissima e ,strano ma vero, l'ho capita.

io credevo che la modifica del tcp/ip fosse una cosa più semplice e solo a lato client.. ma non credevo (non avevo minimamente pensato) che effettivamente il "Mio" fastpath avrebbe raggiunto il mio provider... e ovviamente non ne sarebbe passato inosservato... anzi...

credevo che la cosa fosse stata più leggera e che se io decidevo di togliere il controllo errori.. mi sarei preso da solo le mie responsabilità, restando, quindi, legale sotto tutti i punti di vista!

porcaccia.. torno sempre al solito discorso.... ci vuole che alice dia la possibilità all'utente di decidere se attivare o no la linea in fast path specificando che quest'ultimo si sarebbe preso ogni responsabilità sui probabili errori riscontrabili..

per me il fast path è un discorso di vita o di morte...

comunque se qualcuno sa come approfondire ulteriormente l'argomento o ha qualche brillante idea è ben accolto!

grazie nuovamente a tutti

si', ma tu avresti dovuto capire quello che ha detto edivad82 :D

TheBenchmarkSHuB

09-03-2005, 18:05

Ciao marwi dopo un atenta analise di quanto teoricamente tratato qui posso concordare con te di una necessita nel avere un flusso continuo in certe aplicazione e quest ultima da me riportata piu in basso potra sembrare un OT ma non lo è :

Dunque parlando di "stabilita di latenza" sul protocollo che influisce sullo streamming ti posso dire che non è ancora di dominio "publico" il nuovo IPv6 (standard del ip) abbiamo dalla nostra comunque il RSVP che non fa altro che cercare di mantenere una buona qualita di flusso dati in rete, per farla breve il (QoS) che cerca di mantenere e quindi permetere l audio e video nel suo ragiungimento (user) senza interuzioni;)
questa non è forse il motivo delle tue domande riguardo alla latenza (era il PING/Fastpath e la eventuale disabilitazione dell'ICMP) ma svolge anche questo protocollo una funzione di notevole importanza per cio che riguarda lo streamming o aplicazioni che richiendono tempi di latenza (o stabilita) migliori,il gamming è infati composto da fonti audio ad esempio e questo è un flusso.
Puntoalizo che questo tema da me acenato è un servizio relazionato con il Web e provider (come categoria) e con il TCP/IP
perchè il servizio (QoS) puo essere inserito (abilitato) o non utilizato a seconda della necessita dell utente (user pc).
Concludo comunque dicendo che problabile ci venga piu agli occhi il nome "PING Basso" o "Fastpath" piutosto che protocolli (di rete e non solo locale) e servizi integrati in Windows che sostengono tutto quel Entertainment di cui possiamo disporre quando ci colleghiamo online:doh:
Riguardi:)
ps: Hey avevi ragione sai :-) lo puoi fare !!!
Si quello disabilitare il

ICMP (http://home.tiscalinet.ch/winzozzz/SP2-20c.png)
ma con uno dei due Service Pack:ronf:

marwi

10-03-2005, 01:14

non è che ho capito bene quello che intendi dire.... (sono ignorante :D )

altra cosa, la finestra che mostri nello shot com'è raggiungibile?

da come ho capito però da quella finestra possono essere solo spuntati dei parametri in più riguardo l'icmp, ma non ho ancora capito come possiamo eliminare questo "dannato" controllo degli errori.....

i nostri pacchetti sono più grandi del loro dovuto perchè contengono informazioni riguardo gli errori. C'è un modo per far si che questi pacchetti non vengano "Ingrassati" ?? riprendendo il discrorso della legalità di questo atto... ossia se scoperto.. può essere perseguito?

TheBenchmarkSHuB

10-03-2005, 10:09

Ciao,
cio che cercavo di dirti è che anche se hai il ping alto (no Fastpath) ci sono altri servizi e protocolli che farano in modo che (magari non per latenza con ping bassi) tu possa avere un flusso dati costante e stabile !

QUI (http://punto-informatico.it/p.asp?i=48239) ti rendi conto che non è fattibile in casa la cosa:)

Schum4k3r

10-03-2005, 11:18

Originariamente inviato da Furbastro
Il settaggio in fast che ti fanno in centrale permette al router di trattare diversamente i pacchetti.In questo modo il tempo di transito diminuisce.Guarda che se riduci di molto la dimensione dei pacchetti agendo sulla MTU rischi di ottenere l'opposto di quello che vuoi fare, perche' aumenti a dismisura l'overhead con il risultato che mandi piu' header che dati.Ci sarebbe molto da dire a riguardo.In sintesi, cmq, e' che se disabiliti l'ICMP non riesci ad ottenere l'aumento di velocita' di transito dei pacchetti che tu auspichi di avere.Cmq l'ICMP non fa il controllo di errore, ma gestisce altri servizi come l'"echo request/replay" aka "ping".

funziona esattemente cosi' ;)
il fast lo devono settare da centrale non esistono altri metodi per abbassare il ping, nemmeno agendo sulla MTU o usando dei programmini ke dicono di abbassare il ping. al max ottimizzano qlcsetta ma niente di miracoloso

Johnn

11-03-2005, 22:24

Andando ancora più sul pesante (e penso sull'illegale, anche se anche io non l'avrei mai immaginato) dal tcp si potrebbe togliere o limitare opportunamente il controllo di congestione. Penso si avrebbe un guadagno superiore all'eliminazione del controllo degli errori.

A proposito, ma come farebbe un ISP ad accorgersi che io sulla mia macchina non controllo i pacchetti in ingresso, a patto che quelli che spedisco hanno il normale controllo degli errori?

Grazie e ciao.

TheBenchmarkSHuB

11-03-2005, 22:42

perche tale opzione è riservata agli ISP
non puoi cambiare le regole cosi..
vuoi che non vedono come viaggiano i dati da e a sulla linea intestata al tuo numero di casa.
a cosa ti riferisci con controllo di congestione:cool: Originariamente inviato da Johnn
Andando ancora più sul pesante (e penso sull'illegale, anche se anche io non l'avrei mai immaginato) dal tcp si potrebbe togliere o limitare opportunamente il controllo di congestione. Penso si avrebbe un guadagno superiore all'eliminazione del controllo degli errori.

A proposito, ma come farebbe un ISP ad accorgersi che io sulla mia macchina non controllo i pacchetti in ingresso, a patto che quelli che spedisco hanno il normale controllo degli errori?

Grazie e ciao.

Johnn

11-03-2005, 23:02

Premetto che sto seguendo il corso di reti all'università, ma partivo da zero conoscenze pregresse.

Il protocollo tcp, protocollo dello stato di trasporto della pila protocollare, offre diversi servizi allo strato di applicazione, come il famoso controllo degli errori, l'affidabilità, cioè la garanzia che un pacchetto spedito arriva a destinazione, il controllo di flusso, cioè evita di intasare il destinatario e offre un servizio più per la "comunità" che per i diretti interessati di una connessione, cioè il controllo di congestione della rete. Se una rete è congestionata e si continuasse a mandare pacchetti, come fa l'UDP, si arriverebbe alla paralisi della rete. Il tcp invece si "accorge" che la rete si sta intasando (per il tcp la perdita di un pacchetto è segnale di congestione) e limita fortemente la spedizione di pacchetti. Praticamente all'inizio ne manda 1 (:eek: , perchè non mandarne 100 subito :angel: ), poi 2, 4, 8, fino ad una certa soglia dopo la quale l'incremento è lineare e non più esonenziale (in parole povere tipo a 64 non ne spedisce 128 ma 65), fino a che non perde un pacchetto (scadenza del timeout senza aver ricevuto risposta dal destinario). A quel punto ricomincia a mandare 1 pacchetto e così via e in più dimezza la soglia. Cmq ci sono nuove versioni del tcp che apportano ottimizzazioni in questo senso, ma la sostanza non cambia, cioè il controllo di congestione è cmq presente.
Ovviamente una cosa del genere è anche abbastanza immorale in quanto va a danneggiare la comunità per puri interessi personali.

Per il controllo degli errori non capisco cosa implicherebbe il fatto che quando mi arriva un pacchetto sulla mia macchina, non nei router, e il pacchetto arriva allo strato di trasporto il tcp non fa il controllo degli errori (che tra l'altro mi sembra faccia anche il livello 2 della pila) e passa direttamente il pacchetto all'applicazione a rischio ovviamente di errori non controllati.

Spero di essere stato chiaro, soprattutto per l'esame che dovrò fare a breve :p .

TheBenchmarkSHuB

12-03-2005, 01:12

io non al vado corso :-) ma vedo come è congestionata ...
Visto che tale servizio della pila protocollare si rende bene conto che abbiamo una rete
cosi intasata, oltre a limitare (e se limita non smaltisce bensi ne limita il trasporto dosandolo :-) e ralentandolo e questo vale anche per chi ha il "fastpath" perche ping alto o basso entrambi i modi settati della conessione ne fano uso del mesionato protocollo) la spedizione dei pachetti verso i destinatari, Dunque mi sai dire che altre soluzioni riesce ad attuare per evitare che il destinatario resti senza la informazione da lui richiesto?
Si :-)... quello, "Il tcp invece si "accorge" che la rete si sta intasando (per il tcp la perdita di un pacchetto è segnale di congestione) e limita fortemente la spedizione di pacchetti" qui non vi entra niente perchè se la rete è full non vi è STUDIO universitario (se non aplicativa-alternativa vedi IPV6 o ADSL2) che tenga alla congestione della rete INTERNET (puoi avere anche 6 MB/s ma se il server non smaltisce il trafico,in QUEUE) ed è
cosi che i dati per i "diretti interessati di una connessione" non giungono cosi in tempo (server intassati per congestione da download ad esempio).Altro che la perdita di un pachetto... con server intassati (il tcp)li perde tutti e se non li perde tutti... gli utenti che richiedono i dati perdono tempo :-( e nel bussnes è questione di "tempo"
IO invece sono sicuro di essere stato chiaro, soprattutto per le novita dal mondo tecnologico che piu si sviluppa e piu la rete rischia di collassare, un po come la fame
nel mondo :
ci sono risorse ma non vengono ben distribuite con un certo criterio ed equilibrio !
Originariamente inviato da Johnn
Premetto che sto seguendo il corso di reti all'università, ma partivo da zero conoscenze pregresse.

Il protocollo tcp, protocollo dello stato di trasporto della pila protocollare, offre diversi servizi allo strato di applicazione, come il famoso controllo degli errori, l'affidabilità, cioè la garanzia che un pacchetto spedito arriva a destinazione, il controllo di flusso, cioè evita di intasare il destinatario e offre un servizio più per la "comunità" che per i diretti interessati di una connessione, cioè il controllo di congestione della rete. Se una rete è congestionata e si continuasse a mandare pacchetti, come fa l'UDP, si arriverebbe alla paralisi della rete. Il tcp invece si "accorge" che la rete si sta intasando (per il tcp la perdita di un pacchetto è segnale di congestione) e limita fortemente la spedizione di pacchetti. Praticamente all'inizio ne manda 1 (:eek: , perchè non mandarne 100 subito :angel: ), poi 2, 4, 8, fino ad una certa soglia dopo la quale l'incremento è lineare e non più esonenziale (in parole povere tipo a 64 non ne spedisce 128 ma 65), fino a che non perde un pacchetto (scadenza del timeout senza aver ricevuto risposta dal destinario). A quel punto ricomincia a mandare 1 pacchetto e così via e in più dimezza la soglia. Cmq ci sono nuove versioni del tcp che apportano ottimizzazioni in questo senso, ma la sostanza non cambia, cioè il controllo di congestione è cmq presente.
Ovviamente una cosa del genere è anche abbastanza immorale in quanto va a danneggiare la comunità per puri interessi personali.

Per il controllo degli errori non capisco cosa implicherebbe il fatto che quando mi arriva un pacchetto sulla mia macchina, non nei router, e il pacchetto arriva allo strato di trasporto il tcp non fa il controllo degli errori (che tra l'altro mi sembra faccia anche il livello 2 della pila) e passa direttamente il pacchetto all'applicazione a rischio ovviamente di errori non controllati.

Spero di essere stato chiaro, soprattutto per l'esame che dovrò fare a breve :p .

Black imp

12-03-2005, 12:11

Originariamente inviato da Vecchia Spugna
Io sono + ignorante di te(e ce ne vuole:D )
Però secondo me se fosse possibile qualcuno l'avrebbe fatto.
Tuttavia alle mie enormi orecchie :p non è mai giunta tale notizia, quindi ne deduco per modus ponens (scusate il riferimentoi, ma sn fresco di esame di logica) che nessuno l'ha mai fatto, quindi deduco a sua volta che non sia possibile :sofico:

Ciauuuuuu

se neghi una condizione necessaria a memoria mi sembra che usi il modus TOLLENS

:)

Johnn

12-03-2005, 15:07

X TheBenchmarkSHuB

Intendi dire che la rete è congestionata? Da che lo capisci? Non so se è un buon test. ma quando scarico file di grosse dimensioni su server decenti, vado sempre al max.

E' ovvio che se tutti eliminassero il controllo della congestione la rete, come ho già detto, collasserebbe (vedi udp). Ma se in internet solo io mi disinteresso della congestione, contando che gli altri la controllano, non dovrei avere grossi problemi (mica con il mio traffico riesco a paralizzare la rete, no?). Considera cmq che il tcp recupererebbe comunque eventuali pacchetti persi una tantum per congestione.

Anche se non so bene come funziona effettivamente il settaggio fast, è logico che non c'entra con l'intasamento della rete, non è che una connessione fast ha la corsia preferenziale!

Non ho ben capito la frase:

" Dunque mi sai dire che altre soluzioni riesce ad attuare per evitare che il destinatario resti senza la informazione da lui richiesto? "

Per il fatto della crescita della rete, sempre dal corso, ho imparato che la struttura della internet attuale è nata parecchio tempo fa e non era stata lontanamente progettata per usi come quelli di oggi, ad esempio contenuti multimediali o voip, che richiedono più una banda costante che l'affidabilità di ciò che è trasportato. Tuttavia in qualche modo regge. Non indifferente è anche l'aumento imprevisto del traffico "pesante" del file sharing, nel giro di pochissimi anni, che usa la stessa infrastruttra pensata per scambiarsi e-mail e al max qualche pagina html!

TheBenchmarkSHuB

12-03-2005, 16:32

Sai anche come è ben congestionata...
Poi il 56k era gia un monitor (per svilupatori che gia vedevano lo stato della rete guardando ad un utenza di massa del ADSL) e riassumeva (vedi flat) molto di cio che dici qui oggi, gia alora!
:) " Dunque mi sai dire che altre soluzioni riesce ad attuare per evitare che il destinatario resti senza la informazione da lui richiesto? "
vedi mi dai ragione, se vai al sito del grande fratello nel momento di massima itenza non importa a quanto scarichi "al max giusto :-)
in coda,si anche tu come tutti intassi la rete perche trasferisci e ricevi, non importa a che velocita (e la alternativa che hai è?).
il tcp recuperera anche i pachetti come dici ma se il server ti butta fuori ( :-) bhè.. non devi far altro che recuperare il tempo di atesa che hai perso.
non è vero che i "contenuti multimediali o voip, che richiedono più una banda costante che l'affidabilità di ciò che è trasportato" altrimenti non servirebbe a un gran che il "fasth" (ad esempio se uno controlla spesso la borsa di Tokio o streeming con flusso audio e video) lo stesso per il servizio di rete (QoS) anche esso indispensabile per i contenuti multimediali:)quindi l'affidabilità mi garantisce il flusso costante nel ricevere e visualizare i contenuti da noi richiesti, se il flusso è affidabile appunto.

Johnn

12-03-2005, 19:14

Originariamente inviato da TheBenchmarkSHuB
...
Poi il 56k era gia un monitor (per svilupatori che gia vedevano lo stato della rete guardando ad un utenza di massa del ADSL) e riassumeva (vedi flat) molto di cio che dici qui oggi, gia alora!

Io mi riferivo agli anni in cui la rete e i protocolli nacquero per connettere principalmente università, cioè anni 70-80 e non all'epoca dei 56k ben più recente.

Originariamente inviato da TheBenchmarkSHuB
:) " Dunque mi sai dire che altre soluzioni riesce ad attuare per evitare che il destinatario resti senza la informazione da lui richiesto? "
vedi mi dai ragione

In che senso ti ho dato ragione? Avevo solo riportato la tua frase :what:

Originariamente inviato da TheBenchmarkSHuB
se vai al sito del grande fratello nel momento di massima itenza non importa a quanto scarichi "al max giusto :-)
in coda,si anche tu come tutti intassi la rete perche trasferisci e ricevi, non importa a che velocita (e la alternativa che hai è?).
il tcp recuperera anche i pachetti come dici ma se il server ti butta fuori ( :-) bhè.. non devi far altro che recuperare il tempo di atesa che hai perso.

Frase un po' contorta e ricca di errori. Non ho capito! (Questo è un esempio di pacchetto corrotto! Io, in questo caso il ricevente, comunico al mittente, tu, che non ho capito e chiedo di rispedirmi il messaggio).

Originariamente inviato da TheBenchmarkSHuB
non è vero che i "contenuti multimediali o voip, che richiedono più una banda costante che l'affidabilità di ciò che è trasportato" altrimenti non servirebbe a un gran che il "fasth" (ad esempio se uno controlla spesso la borsa di Tokio o streeming con flusso audio e video) lo stesso per il servizio di rete (QoS) anche esso indispensabile per i contenuti multimediali:)quindi l'affidabilità mi garantisce il flusso costante nel ricevere e visualizare i contenuti da noi richiesti, se il flusso è affidabile appunto.

Io per affidabilità intendo la garanzia che un pacchetto arrivi sicuramente a destinazione e in più in maniera integra, cioè così come è stato inviato. Per un applicazione multimediale, tipo un video, non è tanto importante che un pacchetto arrivi corrotto, al max vedi un piccolo disturbo, ma che il flusso sia costante per non avere interruzioni. Il QoS non so cosa sia.

TheBenchmarkSHuB

12-03-2005, 20:12

Vero hai riportato la mia frase ma...

TU: 11-03-2005 23:02

Il tcp invece si "accorge" che la rete si sta intasando (per il tcp la perdita di un pacchetto è segnale di congestione) e limita fortemente la spedizione di pacchetti

IO: 12-03-2005 01:12
" Dunque mi sai dire che altre soluzioni riesce ad attuare per evitare che il destinatario resti senza la informazione da lui richiesto? "

...e come vedi siamo sulla stessa frequenza oltre che THREAD ma non ti sei reso ancora conto di non aver risposto alla mia domanda iniziale mensionando pure il livello di trasporto UDP che non è affidabile ed è senza connessione (non come il TCP il quale gestisce l'organizzazione dei dati e il controllo della trasmissione di questi ultimi) se non fosse per L'unita' di trasferimento dati che e' il pacchetto IP ed è inoltre consigliabile nel utilizo aplicativo (locale) per la sua inafidabilita perchè con gli UDP non viene garantita la consegna e l'ordine di arrivo dei datagrammi.

ps:

TU: 11-03-2005 22:24
Andando ancora più sul pesante (e penso sull'illegale, anche se anche io non l'avrei mai immaginato) dal tcp si potrebbe togliere o limitare opportunamente il controllo di congestione

non capirai le mie di domande ma le tue introduzione sono decisamente BHO :rolleyes: (esempio "pachetto mai spedito" tu "mai ricevuto" i lettori del THREAD:)
quando sara pronto lo standard ADSL2 non mi dirai ancora:blah: che " i protocolli nacquero per connettere principalmente università, cioè anni 70-80 e non all'epoca dei 56k ben più recente. "
:cool: non ha senso !
o potenziano la infrastuttura (servers /users capacity) e "aprono i rubinetti (isp)" erogando piu bandwidth oppure non la pigliare con Vinton Cerfe Robert Kahn che hanno dato il via a un qualcosa che oggi come gia detto è mal sfruttatoe... se pensi che vennero realizzate adiritura quattro versioni nella seconda metà degli anni '70 il tempo dopo gli ani 90 è stato galantuomo per permettere agli svilupatori/ricercatori di potenziare ed evolvere
il protocollo da te analizato "grazie libri" ma che ti porta come tutti ad una realta ben piu paradosale ed assurda !
INTERNET non regera questo non avanzamento delle soluzione alternative "ipv6 ADSL2" che ne migliorerebbero certamente la qualita e navigabilita senza dubbio;)

Johnn

12-03-2005, 21:56

Ti chiedo per piacere di rileggere quello che scrivi prima di postare, perchè ci sono sempre parecchi errori. Non voglio polemizzare, è solo per comprendere meglio ciò che vuoi dire. :)

L'udp l'ho mensionato per due motivi principali e confermo che è profondamente diverso dall'tcp:
1) è più indicato per applicazioni come voip streaming audio-video e per applicazioni che richiedono tempi di risposta brevi, come ad esempio il dns;
2) il protocollo udp si disinteressa dello stato della rete (in contrapposizione al tcp): se la rete è intasata e perde pacchetti, la sorgente udp continua a pompare pacchetti come se nulla fosse, aggravando di fatto la situazione.

Purtroppo l'adsl2 non la conosco. Ma in generale le innovazioni tecnologiche, penso ad esempio alla fibra ottica, seppur sono conosciute e si sa come farle funzionare, sono fortemente penalizzate dal fatto che si dovrebbe spendere tempo e denaro per gli aggiornamenti delle apparecchiature esistenti (in due parole, per la fibra ottica scavare come fa fastweb). L'ipv6 che è alle porte (già da un po', ormai), si affermerà lentamente: praticamente devono essere aggiornati i router e non è facile gestire la transizione durante la quale coesistono le due versioni (ipv4-ipv6).
La difficoltà di cambiamenti radicali, soprattutto quelli che riguardano gli strati più bassi della pila protocollare, fanno sì che ci si adatti ad utilizzare, ad esempio, il tcp per applicazioni nate molto dopo e per cui non era stato progettato, piuttosto che ristrutturare radicalmente la rete con soluzioni su misura per applicazioni moderne.

Ti sarei grato se puoi riporre la domanda a cui non ti ho risposto.

Ovviamente se qualcun'altro vuole inseririsi nella discussione è bene accetto! :)

TheBenchmarkSHuB

12-03-2005, 22:50

Cosa non hai capito tu?
io ancora che tu esponga le tue tesi "pratiche " su
Andando ancora più sul pesante (e penso sull'illegale, anche se anche io non l'avrei mai immaginato) dal tcp si potrebbe togliere o limitare opportunamente il controllo di congestione
parole tue !!!!
come lo togli quel controllo ?
evita le polemiche ;)

.........
Originariamente inviato da Johnn
Ti chiedo per piacere di rileggere quello che scrivi prima di postare, perchè ci sono sempre parecchi errori. Non voglio polemizzare, è solo per comprendere meglio ciò che vuoi dire. :)

L'udp l'ho mensionato per due motivi principali e confermo che è profondamente diverso dall'tcp:
1) è più indicato per applicazioni come voip streaming audio-video e per applicazioni che richiedono tempi di risposta brevi, come ad esempio il dns;
2) il protocollo udp si disinteressa dello stato della rete (in contrapposizione al tcp): se la rete è intasata e perde pacchetti, la sorgente udp continua a pompare pacchetti come se nulla fosse, aggravando di fatto la situazione.

Purtroppo l'adsl2 non la conosco. Ma in generale le innovazioni tecnologiche, penso ad esempio alla fibra ottica, seppur sono conosciute e si sa come farle funzionare, sono fortemente penalizzate dal fatto che si dovrebbe spendere tempo e denaro per gli aggiornamenti delle apparecchiature esistenti (in due parole, per la fibra ottica scavare come fa fastweb). L'ipv6 che è alle porte (già da un po', ormai), si affermerà lentamente: praticamente devono essere aggiornati i router e non è facile gestire la transizione durante la quale coesistono le due versioni (ipv4-ipv6).
La difficoltà di cambiamenti radicali, soprattutto quelli che riguardano gli strati più bassi della pila protocollare, fanno sì che ci si adatti ad utilizzare, ad esempio, il tcp per applicazioni nate molto dopo e per cui non era stato progettato, piuttosto che ristrutturare radicalmente la rete con soluzioni su misura per applicazioni moderne.

Ti sarei grato se puoi riporre la domanda a cui non ti ho risposto.

Ovviamente se qualcun'altro vuole inseririsi nella discussione è bene accetto! :)

Johnn

12-03-2005, 23:41

Per ignoranza non so dove risiede il codice che gestisce il protocollo tcp. In linux mi sembra si trovi nel kernel.

Ovunque esso sia direi di eliminare il meccanismo che dopo la scadenza di un time-out ricominci con lo spedire un pacchetto solo e incrementare esponenzialmente fino al valore di soglia (anch'esso da eliminare). In altre parole l'obiettivo sarebbe quello di rendere il più costante possibile la spedizione dei pacchetti, piuttosto che avere un comportamento altalenante.

Andando a spulciare il libro su cui devo studiare ho notato che il tcp ha diverse versioni: la prima, e quella a cui ho fatto riferimento, è la Tahoe che si comporta più ho meno come avevo descritto nei post precedenti. Invece ci sono due versioni più recenti che si chiamano Reno e Vegas. La Reno ha eliminato la fase di partenza lenta dopo una scadenza del timeout.
Il Vegas addirittura cerca di prevenire la congestione andando ad analizzare i tempi con cui vengono ackati* i pacchetti spediti: se questi tempi aumentano allora rallenta il flusso di spedizione.

In un certo senso ciò che volevo fare io, il Vegas fa anche meglio.

*ackati: se A manda a B un pacchetto che arriva correttamente, allora B spedisce ad A un "ack" (acknowledgement) per notificare che il pacchetto è arrivato. Spero di essermi spiegato.

TheBenchmarkSHuB

13-03-2005, 01:11

:) si ti seguo e il Vegas mi interessa molto, cosi se il flusso di spedizione aumenta possiamo vedere un filmatino online stando tranquili che non ci sarano interuzioni grazie al check sui pacchetti spediti.

Johnn

13-03-2005, 14:34

Ci sono ancora :) , solo che devo studiare e non ho tanto tempo per approfondire adesso il Vegas, spero che stasera avrò più tempo.
Comunque ti posso dire che sul libro dice in più solo che il Vegas non è comunemente utilizzato al contrario del Reno.

Un interessante programmino per visualizzare il comportamento dinamico di una rete si chiama Nam e lo potete scaricare qui (http://www.isi.edu/nsnam/nam/)
La fonte principale delle descrizioni dei funzionamenti dei protolli di rete utilizzati in internet è la raccolta di RFC (request for comment). Le potete trovare qui (http://directory.google.com/Top/Computers/Internet/RFCs/).

TheBenchmarkSHuB

13-03-2005, 15:23

io invece sto smontando la MB e comunque Grazie da parte di tutti per il link e il tempo che ci hai dato:)
Gia scelto il Vegas come Test:D
Ciao buon studio:sperem:

Johnn

13-03-2005, 22:31

Un altro link è questo (http://utenti.lycos.it/leonix/)

e questo (http://flophouse.com/~neal/uw/linux-vegas/) .

Purtroppo non li ho ancora letti ma mi sembrano interessanti, soprattutto il secondo.

:)

Non mi aspettavo che il vegas avesse 11 anni!

Ho trovato il codice del kernel 2.6.10 di linux inerente il vegas! :eek:

Non è che ci capisco molto, soprattutto da uno sguardo superficiale, quindi non saprei neanche cosa postarvi. Se vi volete scaricare il kernel sono 43 Mb circa. Se qualcuno non ha l'Adsl posterò il codice.

edivad82

14-03-2005, 00:12

Originariamente inviato da Johnn
Andando ancora più sul pesante (e penso sull'illegale, anche se anche io non l'avrei mai immaginato) dal tcp si potrebbe togliere o limitare opportunamente il controllo di congestione. Penso si avrebbe un guadagno superiore all'eliminazione del controllo degli errori.

A proposito, ma come farebbe un ISP ad accorgersi che io sulla mia macchina non controllo i pacchetti in ingresso, a patto che quelli che spedisco hanno il normale controllo degli errori?

Grazie e ciao.
si, ma tutto questo, per fare che?

avresti solo svantaggi...in ogni caso, quello che alza il tempo è il buffer interleaved sulla tratta atm dove i pacchetti sono incapsulati (point to point protocol over atm, ovvero PPPoA) e quindi il tcp poco ci ha a che fare...nella tratta dell'isp in tcp si è si in tcp, ma senza controllo errori, che usi a fare tcp che di per se è un protocollo affidabile?

Johnn

14-03-2005, 09:45

L'obiettivo di eliminare il controllo di errori sarebbe quello di diminuire l'overhead (anche se non saprei quantificarlo, soprattutto in rapporto alla percentuale di pacchetti effettivamente corrotti) per la verifica se un pacchetto è effettivamente corrotto: l'applicazione quindi riceverebbe i dati prima. Non escludo che sarebbe un guadagno trascurabile.

L'obiettivo di eliminare il controllo di congestione, o di modificarlo, sarebbe quello di avere un traffico, almeno in uscita, il più costante possibile. Non mi sembra che in questo caso ci possano essere svantaggi da parte del sender.

Ovviamente con le suddette modifiche sicuramente non si avrebbe nessun aumento di banda, ma forse un utilizzo migliore, insomma un'ottimizzazione.

Certo non saprei quntificare gli eventuali vantaggi, anche perchè non conosco eventuali altri colli di bottiglia come dici tu.

Mi puoi spiegare quale tempo alza il buffer interleaved sulla tratta atm?

edivad82

14-03-2005, 13:51

Originariamente inviato da Johnn
L'obiettivo di eliminare il controllo di errori sarebbe quello di diminuire l'overhead (anche se non saprei quantificarlo, soprattutto in rapporto alla percentuale di pacchetti effettivamente corrotti) per la verifica se un pacchetto è effettivamente corrotto: l'applicazione quindi riceverebbe i dati prima. Non escludo che sarebbe un guadagno trascurabile.

L'obiettivo di eliminare il controllo di congestione, o di modificarlo, sarebbe quello di avere un traffico, almeno in uscita, il più costante possibile. Non mi sembra che in questo caso ci possano essere svantaggi da parte del sender.

Ovviamente con le suddette modifiche sicuramente non si avrebbe nessun aumento di banda, ma forse un utilizzo migliore, insomma un'ottimizzazione.

Certo non saprei quntificare gli eventuali vantaggi, anche perchè non conosco eventuali altri colli di bottiglia come dici tu.

Mi puoi spiegare quale tempo alza il buffer interleaved sulla tratta atm?

per avere un servizio affidabile è necessario un controllo errori, proprio se ti serve un servizio connection oriented...

il buffer interleaved in confronto ad un fast aumenta di circa una trentina di millisecondi il tempo di latenza, se poi tieni conto che ogni switch atm aggiunge 1ms ed un router circa 10ms presto è fatto il calcolo...

TheBenchmarkSHuB

16-03-2005, 18:14

Caro Johnn:asd: nel ringraziarti per il tempo che ci hai concesso (sotraendolo allo studio :-) ho pensato che ti potesse fare comodo un analizatore di rete cosi da potenziare e... supportare meglio il tempo di studi che ti :muro:atendono

*TheBenchmarkSHuB (http://www.anasil.net/);)
non esitare se hai idee projeti e opinioni, giusto postale qui:cool:
TBHs:) 18.12 16/03/2005
Originariamente inviato da Johnn
Un altro link è questo (http://utenti.lycos.it/leonix/)

e questo (http://flophouse.com/~neal/uw/linux-vegas/) .

Purtroppo non li ho ancora letti ma mi sembrano interessanti, soprattutto il secondo.

:)

Non mi aspettavo che il vegas avesse 11 anni!

Ho trovato il codice del kernel 2.6.10 di linux inerente il vegas! :eek:

Non è che ci capisco molto, soprattutto da uno sguardo superficiale, quindi non saprei neanche cosa postarvi. Se vi volete scaricare il kernel sono 43 Mb circa. Se qualcuno non ha l'Adsl posterò il codice.