stack tcp/ip

ice :

Lo stack non dovrebbe "girare" in background: normalmente sta fermo. Ci sono le parti che vengono chiamate (in modo sincrono) dall'applicazione. E ci sono le parti che vengono svegliate da un timer o dall'interfaccia di rete. Queste a loro volta possono chiamare direttamente o svegliare in maniera asincorna l'applicazione. A meno di non aver bisogno di alta efficienza, non sono compiti molto gravosi.

L'implementazione è concettualmente semplice, ma nasconde un milione di trappole, e va fatta con calma e leggendo gli standard.

Il 11/10/2012 08:56, ice ha scritto:

o si può fare qualcosa di più "diretto"?

Io ti consiglio di prendere qualcosa di già fatto e testato. Se lo stack di microchip non ti convince, prendi in considerazione uIP:

Ha alcune limitazioni, ma per fare cose semplici (tipo interfacce telnet e cose simili) va benissimo.

Scrivere e debuggare uno stack da zero richiede veramente tanto lavoro (mesi). Se lo fai per imparare/divertimento va bene, altrimenti direi che è assolutamente sconsigliabile da un punto di vista professionale.

Francesco Sacchi :

Con l'assistenza di una persona capace bastano poche settimane, ma è comunque un lavoro non piccolo, e se c'è qualcosa di già fatto in effetti io seguirei quella strada.

Il 11/10/12 08:56, ice ha scritto:

cpu ai vari task dello stack a turno; in questo modo ovviamente anche il codice specifico dell'applicazione deve essere suddiviso in piccoli task;

pic32, dspic, ...) sia con che senza o.s. e a quanto pare, non ho provato, può essere compilato sia con il c30 sia con altri compilatori C

Peccato che sei su pic, io lo sto facendo su AVR (atmega328 e simili), in C++. Ho già implementato ARP, IP (senza frammentazione) e ICMP. Da poco ho iniziato UDP, ma questo è cosa sa poco.

Lo strato fisico per ethernet è ENC28J60. Il mio obbiettivo è fare un router tra internet e dispositivi wireless in 802.15 (tramite MRF24J40). Gli stessi dispositivi 802.15 avranno IP/UDP come stack, e quindi saranno perfettamente raggiungibili da internet.

Per quanto riguarda TCP...ci sto riflettendo.

Molto c'è già fatto, lo so, ma il bello è proprio rifare...:-)

Un bel giorno pot digitò:

La Microsoft ha impiegato circa quindici anni per fare uno stack TCP/IP decente, cosa ti fa pensare che "una persona capace" impieghi poche settimane? :)

--
Fletto i muscoli e sono nel vuoto.

dalai lamah :

Prima di tutto la Microsoft ha essenzialmente preso il codice BSD e ci ha fatto i guai "migliorandolo". Secondo, quello non è uno stack "decente", è uno generico che rispetto a uno decente richiede almeno cento volte più lavoro, se basta. Per uno "decente" intendo uno che a basse velocità e con applicazioni educate funziona e non si blocca mai. Terzo, come qualcuno mi faceva notare in privato, con le "poche settimane" forse ho esagerato. Ma forse no. Anni fa feci una consulenza per l'implementazione di un TCP/IP su un microprocessore a 8 bit. Ripensandoci, ci volle qualche mese. Ci lavorava un solo, bravissimo programmatore, ma non so quanta parte del suo tempo ci dedicasse, ho idea che in parallelo facesse anche molto altro. Da qui la mia stima, in effetti non verificabile, di "poche settimane".

p56d :

Perfettamente non so, una volta c'erano tanti che bloccavano porte UDP. Magari ora va meglio, ma fai un po' di prove prima.

Lì viene il bello :)

«dove c'è gusto non c'è perdenza»

Il 11/10/12 22:57, pot ha scritto:

L'UDP viene molto utilizzato per lo streaming audio/video (credo anche Skype), nonchè per il DNS. A parte le ovvie differenze con TCP, non ci sono problemi di NAT o blocchi di porte (a meno che non siano volontari, ma questo lo decidiamo noi).

Bello perchè difficile, non impossibile (anche perchè qualcuno l'ha già fatto). Il problema è la memoria per memorizzare tutti gli stati di ogni connessione. Per questo sto valutando anche altre piattaforme: mi alletta molto il launchpad stellaris della TI (16K di ram e 128K di flash per meno di 5 euro, programmatore incluso!).

e si!

p56d :

Per quanto ne so (ma accento smentite documentate) praticamente tutto lo streaming odierno passa su TCP. Skype semplicemente le prova tutte, alla peggio riesce a usare la porta 80 su TCP. Il DNS va sia su UDP che su TCP, e che io sappia se UDP non funziona usa TCP.

Insomma, nessuno dei motivi che citi è una buona ragione per pensare che UDP passi tranquillamente.

Per accertartene, fai delle prove prima di cominciare.

La memoria necessaria è molto piccola, se ti accontenti di prestazioni (molto) scarse. Una sola connessione alla volta, un buffer di dimensione pari al pacchetto più lungo che vuoi inviare. Più ti allontani da queste specifiche più la complicazione cresce. E se vai per quella strada, la memoria che serve è quella per i buffer, gli stati non sono un problema.

Con 16K di ram avresti spazio per pochi buffer da 1500kB. O hai una gestione sofisticata della memoria o più di poche connessioni non ne puoi fare. E se non sei un mago della programmazione sarà difficile farci entrare qualche applicazione.

Auguri :)

Il 12/10/12 09:59, pot ha scritto:

Che intendi esattamente per "UDP passi tranquillamente", cioè, chi dovrebbe bloccarlo? A meno che tu non imposti il tuo model/router per bloccare UDP.

Questo è documentato :-) UDP è nattabile, accertato!

p56d :

Uno qualunque delle miriadi di router e firewall che stanno fra i due host che vogliono comunicare. Siccome hai scritto "MRF24J40). Gli stessi dispositivi 802.15 avranno IP/UDP come stack, e quindi saranno perfettamente raggiungibili da internet." ho messo in dubio che siano perfettamente raggiungibili. In generale sì, ma può darsi che no.

Tipo che VOIP e' SOLO UDP?

Guarda che tutto quello che passa su IP viene consegnato dai provider (GRE,IPSEC,IP2lp,ICMP ecc ecc)

forse e dico forse BGP e altri protocololli usati per gestire gli AS non vengono consegnati , ma dubito(apparte fastweb che e' un mondo a se).

Poi possiamo discutere di NAT e FIREWALL , ma quella e' un altra cosa.

Giulia

Giulia :

Voip è molto generico. Come dicevo, Skype le pensa tutte per passare ovunque, anche usando connessioni TCP, se necessario. Quindi se Skype passa, ancora non vuol dir nulla.

Le applicazioni SIP invece usano solitamente UDP (anche se possono usare TCP). Quindi se un'applicazione SIP funziona è un buon indizio che UTP non sia interamente bloccato. Ma non è detto che non abbia altri problemi.

Magari fosse...

E non ci sono solo i provider. Ci sono anche le reti locali finali, ognuna delle quali può avere proprie regole di firewall.

Veramente non è un'altra cosa, è proprio quello il problema. Se c'è un firewall di mezzo che blocca una certa porta UDP, non è più vero quel che diceva p56d: «avranno IP/UDP come stack, e quindi saranno perfettamente raggiungibili da internet». Va verificato sulla tratta di interesse.

che

Nah.. UDP/TCP sono a livello di trasporto, VOIP è roba a livello di appli cazione. Puoi fare passare pacchetti applicativi su quale protocollo di trasporto ti pare, poi ovviamente ci saranno pro/contro di ogni scelta. Comunque skype, per dirne una, usa UDP con fallback su TCP. Ciao!

Il 12/10/12 12:56, pot ha scritto:

nessun router pubblico blocca UDP (ma neanche ICMP).

Siccome hai scritto "MRF24J40). Gli

Si ma lo stack 802.15 lo scrivo (ed è lo stesso) io e quindi decido io cosa passa e cosa no...:-)

Il 12/10/12 14:53, pot ha scritto:

va bene, ma questo è indipendente da UDP. Potrebbero bloccare anche TCP! Ovviamente va verificato tutto il percorso, ma ripeto, questo è indipendente dal protocollo utilizzato. Per assurdo nella rete dove lavoro io fanno passare solo SNMP (a scopo della sola gestione e monitoraggio degli switch) che appunto lavora su UDP, e bloccano tutte le connessioni TCP.

Il giorno giovedì 11 ottobre 2012 14:45:13 UTC+2, Francesco Sacchi ha scr itto:

non è che non mi convince... è che per essere portatile è pieno di co dice condizionale e ci vuole un po' a capire tutto per bene (certo non come scrivere lo stack from scratch); poi è chiaro che se uno lo "butta" su così com'è va di sicuro ma a me come filosofia non piace avere dei pezzi di codice che vanno ma non so per chè!

comunque in questi giorni l'ho snellito parecchio tenedo solo le parti per il compilatore che mi interessa e per la mia architettura specifica; inoltr e ho spostato in hardware quello che potevo (il modulo di i/o verso eth sup porta già in hw alcuni layer)

uIP l'avevo sentito nominare più volte però mi interessava di più lwI P che è licenziato sotto BSD ed quello su cui si basa BeRTOS o sbaglio?

-ice-

Lasciali perdere, e' ovvio che se ci sono firewall in mezzo non stiamo parlando piu' di "internet" ma di una lan o di una rete privata di un provider(come FW ) ad esempio o di cose castrate come le lan private 3G di vodafogna, se il provider e' neutrale(e lo scegli tu) non ci sono questi problemi.

Giulia

CP!

rlando piu' di "internet" ma di una lan o di una rete privata di un provide r(come FW ) ad esempio o di cose castrate come le lan private 3G di vodafog na, se il provider e' neutrale(e lo scegli tu) non ci sono questi problemi .

Eh? Ma che dici? :-) M'immagino uno al telefono che chiama il provider e chiede "ma voi siete ne utrali?" ;) Scherzi a parte, è infinitamente più probabile essere sotto una LAN (sp ecialmente durante sviluppo e test) che connessi ad un fantomatico provide r che non filtra nulla (credo non possano farlo neanche se vogliano, e non vogliono - forse solo con un contratto di housing), quindi il problema non si pone. Ciao!