Ne sparo una ... TCP/IP

[TheBenchmarkSHuB]

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

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]

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 ( , perchè non mandarne 100 subito ), 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 .

[TheBenchmarkSHuB]

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 ( , perchè non mandarne 100 subito ), 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 .

[Black imp]

Originariamente inviato da Vecchia Spugna
Io sono + ignorante di te(e ce ne vuole )
Però secondo me se fosse possibile qualcuno l'avrebbe fatto.
Tuttavia alle mie enormi orecchie 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

Ciauuuuuu

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

[Johnn]

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]

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 multimedialiquindi l'affidabilità mi garantisce il flusso costante nel ricevere e visualizare i contenuti da noi richiesti, se il flusso è affidabile appunto.

[Johnn]

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

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 multimedialiquindi 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]

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 (esempio "pachetto mai spedito" tu "mai ricevuto" i lettori del THREAD
quando sara pronto lo standard ADSL2 non mi dirai ancora che " i protocolli nacquero per connettere principalmente università, cioè anni 70-80 e non all'epoca dei 56k ben più recente. "
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]

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]

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]

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]

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]

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
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.

[TheBenchmarkSHuB]

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
Ciao buon studio

[Johnn]

Un altro link è questo

e questo .

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!

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]

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]

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]

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]

Caro Johnn 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 atendono

*TheBenchmarkSHuB
non esitare se hai idee projeti e opinioni, giusto postale qui
TBHs 18.12 16/03/2005

Originariamente inviato da Johnn
Un altro link è questo

e questo .

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!

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.

[Johnn]

In fondo ho approfondito lo studio!

Di studio me ne attende parecchio !

Per il programma appena posso gli darò un'occhiata, anche se già sembra promettente.

Non ho capito il fatto delle idee che dovrei postare... Non è che hai già modiicato il tcp come avevo suggerito io e adesso posti dai caraibi all'ombra di una montegna di soldi?