next topic »

[Reply #30 on:]

è solo perché c'è tanta gente che ha sempre difficoltà

Il difficile secondo me non è far funzionare lo shield, ma quello che viene dopo: una volta collegato il cavo ethernet si dovrà creare un qualcosa per la comunicazione e qui se non si ha esperienza è una bella botta; con solo il linguaggio html si fa ben poco, occorre già pensare ad altri linguaggi di supporto tipo javascript oppure php, ajax ecc... e ovviamente più si vuole fare cose particolari più c'è da studiare... se serve un database occorre imparare anche come funzionano i comandi SQL, se si vuole una grafica più gradevole si può ricorrere all'actionScript di flash o imparare il nuovo html5 e via discorrendo.
Altra cosa importante, è che occorre anche avere un pò di nozioni sul funzionamento della connessione, come aprire le porte sul router, come far vedere lo shield dall'esterno della lan... la strada è in salita (ovviamente i soliti mostri diranno "ebbè che ci vuole" ma per un non addetto ai lavori ogni singola cosa diventa un bel problema da affrontare).

Bravo! E' proprio quello che io vorrei risolvere, la problematica iniziale, una volta che si mette in piedi questa allora si possono implementare tutti gli argomenti correlati, bastano esempi banali, ovviamente, poi chiaro che ognuno approfondirà di suo, ma almeno parte da qualcosa; ecco perché è fondamentale l'apporto dei soliti mostri, come li chiami tu

[Reply #31 on:]

partiamo con un poco di basi.

Tanto per cominciare, qualsiasi cosa abbia una scheda di rete può essere nominato come HOST.
Un host può essere un server, ovvero attendere pazientamene che qualcuno gli chieda di fare qualcosa per cui è stato programmato (offrire un servizio), oppure essere un client, cioè colui che richiede il servizio.
Esiste anche la terza possibilità, tipica dei sistemi p2p (peer to peer): ovvero essere contemporaneamente un server e un client. Sono reti parecchio complicate, di cui non discuteremo, e normalmente per entrare a farne parte bisogna conoscere almeno un appartenente attivo alla rete, si può cercare a caso, come ci si può collegare ad un server che mantenga un elenco di host attivi.

Il moderno internet come lo conosciamo, si basa su un sistema a "strati" per poter veder efficacemente inviati i dati. Ogni strato rappresenta uno standard: la scelta dello standard utilizzato varia in base alle proprie necessità. Questo standard di strati si chiama ISO/OSI http://en.wikipedia.org/wiki/OSI_model, e come possiamo vederlo è composto da ben 7 strati, dal livello fisico (cavo ethernet o antenna wifi) fino al livello applicazione(utente), e comprende decine di standard differenti.
Quindi un dato che parte dall'applicazione, entrerà nel livello sottostante gli verrà aggiunto un'header utile alla gestione della rete per quello specifico livello, e inviato nello strato sottostante, dove l'operazione si ripete fino arrivare al livello fisico, dove il dato viene inserito nella rete.


Un collegamento di computer, può essere definito LAN se ottenuto all'interno di una stanza o palazzo, MAN se ottenuto all'interno di una città, WAN se a livello mondiale. Esistono molte altre definizioni, ma queste sono le più utilizzate. Per esempio, collegare i PC di casa è una LAN, internet è una WAN
Esistono vari metodi pr collegare gli host, con un bus (un cavo che passa da PC a PC, passando per ogni HOST una sola volta), una rete ad anello (come il BUS solo che poi il cavo si colega a se stesso. spesso il cavo è doppio, e i dati "girano" in senso opposto), la tipologia "a stella" (un host centrale, di solito un router, è collegato ad ogni singolo host), infine il sistema mesh, in cui ogni host è collegato ad uno o più host in modo più o meno casuale.

Non è difficile immaginare la forza e debolezza di ogni sistema: la rete a bus, se perde un host, può dividersi in due reti separate. Una ad anello, se perde un host resta "fregata", a meno che non usi un doppio anello, nel qual caso funziona lo stesso con qualche rallentamento. se perde anche un secondo host potrebbe iniziare a dividersi in due sottoreti. Una rete a stella non ha problemi nel perdere un host, a meno che non sia l'host centrale, in quel caso cade tutta la rete. Infine la mesh, se ad esempio ogni host è collgato a tutti gli altri host, è virtualmente indistruttibile.
http://en.wikipedia.org/wiki/Computer_network
http://it.wikipedia.org/wiki/Local_area_network

La nostra rete di casa (LAN) è molto differente dalla vera rete internet, di conseguenza abbiamo bisogno di un "traduttore", un qualcosa che srotoli uno o più livelli (anche tutti!) e li ricrei con le impostazione della nuova rete in cui vogliamo entrare.
Questo viene chiamato GATEWAY. Il nostro modem o router di casa fa da gateway, oltre che un altro paio di chicche che vedremo più avanti.
Una precisazione particolare vale per fastweb, che si tratta di una WAN (ovvero una LAN a livello mondiale, come internet, ma è distaccata da essa, e ci comunica attraverso, appunto i gateway)

Un gateway prende il nome dal livello ISO/OSI di rete in cui lavora:
livello 1 - hub o repeater
livello 2 - switch o bridge
livello 3 - router

Benissimo. Osserviamo ancora una volta l'ISO/OSI:

il livello 2, per funzionare, richiede che ogni host abbia un valore numerico differente: è il MAC adress (se non erro 16 byte). Dati e header, in questo livello, vengono chiamati frame.

il livello 3, per funzionare, richiede che ogni host abbia un secondo valore numerico, che al suo interno però contenga un'indicazione della posizione della rete (nulla a che vedere con la posizione geografica!): questo valore viene detto IP. Esiste una parte non modificabile, che appunto rappresenta la posizione della rete, e una modificabile, che rappresenta ogni singolo host (che poi a sua volta può nascondere più host, come vedremo più avanti). Per capire quale sia la parte modificabile e quella no si usa la maschera di rete.
Attualmente esistono 2 versioni di IP:
l'IPv4, che è quello più utilizzato, composto da 4 byte separati da un punto: es. 192.168.1.10. In questo caso la maschera di rete potrebe essere 255.255.255.0: ciò vuol dire che 192.168.1 rappresenta la posizione della rete, mentre il 10 può essere un numero che rappresenta l'host. Quindi in questo caso la maschera di rete ci limita a "soli" 255 host.

Purtroppo, gli IPv4, che sono solo 4.228.250.600, stanno finendo: quindi si è creato l'IPv6, che con 666.000.000.000.000.000.000.000 indirizzi non dovrebbe avere problemi a breve termine (per breve termine si intende mezzo universo colonizzato da host, e si spera anche qualche umano ).
l'IPv6 fondamentalmente è come l'IPv4, solo che usa 16byte (e che sono separati dal : invece che dal . e rappresentati in esadecimale), per esempio: fe80::226:18ff:feba:8b6c, e stessa cosa vale per la maschera di rete.

Dati e header, a questo livello, si chiamano "datagrammi", e già inizia a contenere un TTL, ovvero il numero di rimbalzi massimi tra host che il pacchetto può fare prima di venire distrutto (e poi vi lamentate delle poste!). Nel caso, viene creato un messaggio di errore utilizzando il protocollo ICMP (diagnostica di rete), sempre sul livello 3

Ed infine abbiamo il 4 livello, ovvero quello a cui lavora la nostra ethernet SHIELD! i due standard più famosi a questo livello sono il TCP e l'UDP.
voi potrete scegliere quale dei due standard utilizzare, quindi vediamoli subito in dettaglio....
[continuo più tardi]

[Reply #32 on:]

è solo perché c'è tanta gente che ha sempre difficoltà

Il difficile secondo me non è far funzionare lo shield, ma quello che viene dopo: una volta collegato il cavo ethernet si dovrà creare un qualcosa per la comunicazione e qui se non si ha esperienza è una bella botta; con solo il linguaggio html si fa ben poco, occorre già pensare ad altri linguaggi di supporto tipo javascript oppure php, ajax ecc... e ovviamente più si vuole fare cose particolari più c'è da studiare... se serve un database occorre imparare anche come funzionano i comandi SQL, se si vuole una grafica più gradevole si può ricorrere all'actionScript di flash o imparare il nuovo html5 e via discorrendo.
Altra cosa importante, è che occorre anche avere un pò di nozioni sul funzionamento della connessione, come aprire le porte sul router, come far vedere lo shield dall'esterno della lan... la strada è in salita (ovviamente i soliti mostri diranno "ebbè che ci vuole" ma per un non addetto ai lavori ogni singola cosa diventa un bel problema da affrontare).

Bravo! E' proprio quello che io vorrei risolvere, la problematica iniziale, una volta che si mette in piedi questa allora si possono implementare tutti gli argomenti correlati, bastano esempi banali, ovviamente, poi chiaro che ognuno approfondirà di suo, ma almeno parte da qualcosa; ecco perché è fondamentale l'apporto dei soliti mostri, come li chiami tu

quando avrò finito capirete perchè è così difficile: l'ethernet implementa fino al 4 livello, voi volete utilizzare javascript e simili, che se fossero rappresentati nell'ISO/OSI rappresenterebbero qualcosa tipo il 10 livello.... ed ogni livello diviene via via più complesso, perchè deve mettere a disposizione funzioni sempre più complesse. Insomma, esiste un limite al nostro povero arduino, e anche alla voglia di un programmatore... Inutile fare una libreria PHP quando le stese cose le puoi fare direttamente in C(sempre usando le librerie, ma in C!)
Poi ve la immaginereste la gente che chiede come mai arduino va in time out quando cerca di creare una immagine dinamica o chissà cosa...

forse con la 2 sarete accontentati

[Reply #33 on:]

Bellissimi interventi lesto! OK, non dobbiamo risolvere l'impossibile ma spiegare il possibile, ed il tuo intervento va nella giusta direzione, quando avremo sufficiente materiale metteremo in piedi un bel lavoro di gruppo per la Comunità. Grazie!

[Reply #34 on:]

IL TCP e l'UDP

a questo livello i dati + header vengono chiamati pacchetti nel TCP e datagrammi nell'UDP.

benissimo, finora abbiamo visto come creare un collegamento tra due o più PC, per distinguere le comunicazioni possiamo usare l'IP, oppure un livello aggiuntivo implementato da noi. Ma che succede se uno stesso host vuole collegarsi più volte allo stesso server? in questo caso il nostro programma dovrà implementare un livello per distinguere le differenti connessioni. Ma che succede se il server offre due servizi differenti, ovvero i programmi lato server che accettano connessioni sono 2 o più? Se la distinzione fosse fatta a livello applicativo (ovvero del programma) un bel macello, dato che entrambi i programmi dovrebbero comunicarsi a vicenda per capire a CHI è diretto il messaggio in arrivo. In oltre ho accennato a come un datagramma, o un frame, potrebbe non raggiungere a destinazione, o arrivarci danneggiato, oppure arrivare in disordine: in reti complesse è possibile che i messaggi compiano strade (route) differenti per arrivare a destinazione, e quindi un messaggio inviato DOPO potrebbe arrivare prima del precedente.

Parte di queste problematiche sono già state risolte; a questo livello vengono implementate le porte. Esse sono semplicemente un numero da 0 a 65536: un host viene identificato a partire dal suo IP, la porta che utilizza per inviarci i messaggi, e la nostra porta a cui sono indirizzati i messaggi.

Viene anche implementato l'MTU: ovvero la dimensione massima di un pacchetto o datagramma. Un messaggio che superi questa dimensione, viene frammentato(ovvero suddiviso) in messaggi più piccoli. Questo crea qualche problema nell'uso dell'UDP nella ricostruzione del messaggio

Partiamo dall'UDP, essendo molto più grezzo rispetto al TCP
l'UDP non crea una connessione persistente, ovvero si dice connection-less. Ciò vuol dire che ogni pacchetto inviato è come se fosse una connessione a se. Ogni pacchetto viene inviato tramite una porta a caso su una ben specifica porta del ricevente.
Servono quindi 2 porte: una che viene usata per scrivere il messaggio (outbound) dal client, e una usata per leggerlo (inbound) dal server

Quindi per rispondere, l'ex-ricevente deve sapere la porta aperta nell'ex-trasmittente a cui inviare i dati. In totale servono 4 porte aperte, 2 per host.
Da notare che le porte outbound vengono aperte solo per il tempo necessario all'invio del messaggio, e poi vengono richiuse, mentre le inbound sono sempre aperte in ascolto di messaggi in arrivo.

Se osserviamo un firewall, questo si occupa proprio di bloccare le porte, di solito quelle inbound. Anche la NAT svolge indirettamente questa funzione e va settata, dicendo che i messaggi UDP in arrivo sulla determinata porta vanno ritrasmessi all'host che è in ascolto. Ma vedermo quesa NAT più in particolare dopo.

Vantaggi dell'UDP:
è leggero. Non implementa controlli nè header grossi, quindi occupa poca banda e i messaggi sono elaborati in fretta.
Svantaggi:
Non controlla che i messaggi arrivino a destinazione
Non è detto che controlli l'integrità del datagramma ricevuto, se lo fa e risulta il datagramma errato, viene eliminato come se non fosse mai arrivato a destinazione
Non controlla l'odine di arrivo dei messaggi, dato che essendo connection-less da per scontato che questo controllo non serva
Non fa il controllo di congestione, ovvero non cambia strada (route) se il percorso risulta lento o inaffidabile

Passiamo al TCP:
è molto differente, perchè crea una vera e propria comunicazione a due vie, ovvero una connessione.
Un host che si connette con porta outbound a un server, utilizzerà la porta oubound sia per inviare che per ricevere: ciò vuol dire che usando il TCP, il client per ricevere dati NON ha bisogno che venga toccato il firewall, o la NAT.
Quindi perchè entrambi gli host cominichino bastano 3 porte: una da parte del client per scrivere e ricevere, e 2 da parte del server, una inbound per ricevere e una oubopund per scrivere.

Vantaggi del TCP
Si accorge se un pacchetto è mancante o danneggiato
richiede la ri-trasmissione di un pacchetto se risulta mancante o danneggiato
ordina i pacchetti ricevuti per ordine di invio
Svantaggi del TCP
è pesante, tutti questi controlli, i timeout per le ricezioni dei pacchetti, la necessità di aspettare che un pacchetto precedente arrivi prima di rendere disponibili al socket anche quelli successivi, creano dei grossi ritardi, oltre che un peso aggiuntivo degli header (più del doppio dell'UDP), computazionale per i controlli, e della rete con tutti i messaggi di controllo.

[pausa cena]

[Reply #35 on:]

Grande lesto!!! goditi la cena in pace, quanto stai scrivendo merita già di diventare subito la parte introduttiva teorica della guida, in pratica il Capitolo 1; quando finisci avvisami che mi metto al lavoro

[Reply #36 on:]

Ottimo lesto, come sempre, pero' io direi di metterla come allegato alla fine, mettendolo come introduzione la gente si "appaura"

io sono piu' per partire con il caro blink, ma fatto online, in entrambe le direzioni.

Cioe' nel primo esempio spediamo a patchube il nostro bel segnale che blinckera' una bella onda quadra sul grafico.ù
Nel secondo esempio andiamo al contrario, e cioe' con un bel pc su internet facciamo accendere il nostro bel led13 in blink

Gia' questo che sembra banale affronta il tutto

[Reply #37 on:]

Ora capite perchè ho scritto "mostri" 
Bravo lesto, davvero complimenti per cotanta saggezza

[Reply #38 on:]

Bella iniziativa, ho raccolto diverse paginate di esempi con uso di SD, librerie, webserver che aggiorna il client ogni 500 millisecondi e messe insieme, per quello che riguarda me nessuna riga di HTML è scritta sullo scketch, il prossimo passaggi è quello di prelevare i setup da un file su SD e quello successivo di aggiungere un datalog completo su file, non ho ancora un progetto completo, ma sto ottenendo ciò che mi serve, vediamo quale scia iniziale volete seguire e magari posterò il mio progetto.

ciao

[Reply #39 on:]

Bella iniziativa, ho raccolto diverse paginate di esempi con uso di SD, librerie, webserver che aggiorna il client ogni 500 millisecondi e messe insieme, per quello che riguarda me nessuna riga di HTML è scritta sullo scketch, il prossimo passaggi è quello di prelevare i setup da un file su SD e quello successivo di aggiungere un datalog completo su file, non ho ancora un progetto completo, ma sto ottenendo ciò che mi serve, vediamo quale scia iniziale volete seguire e magari posterò il mio progetto.

ciao

Grazie! In realtà l'idea è quella di raccogliere le esperienze (scritte) di ognuno, anche in contemporanea roba "tosta" e roba "semplice"; il lavoro di riorganizzazione finale poi darà un "filo" a tutto il lavoro. Cioè il lavoro finale non sarà questo Topic, che serve solo per la "raccolta dati", quindi qui ci può anche essere il disordine totale, nel frattempo realizzeremo una bella Guida, a "firma" di tutti coloro che avranno collaborato. Quindi se vuoi inserire la tua esperienza lo puoi fare a prescindere, l'importante è che si possa copia/incollare ed utilizzare come paragrafo finale.

[Reply #40 on:]

Volendo dare il mio contributo all'iniziativa proposta da Michele. Ho scritto queste poche pagine, che voglio aggiornare, se avro' tempo, man mano che imparero' nuove cose in rete su questo argomento molto interessante quale e' la ETHERNET SHIELD e il suo collegamento ad Arduino.

Intanto vi posto questo link e spero che possa essere di aiuto gia' a qualcuno.

http://schianorobotics.altervista.org/arduino.html

Ciao,
Fabrizio.

[Reply #41 on:]

bravo

[Reply #42 on:]

Leggendo i vari problemi riscontrati dagli utenti sulla ethernet shield vedo che molti utilizzano tale la scheda per ottenere lo stesso risultato ma in forma nettamente diversa:

chi vuole comunicare con arduino dal suo palmare con applicazione dedicata
chi vuole inviare dati a un suo server esterno php mysql
chi vuole inviare dati passando da Pachube
chi vuole caricare le pag sulla sd e vederle da un semplice pc remoto
chi vuole usare la scheda solo in lan locale
chi lo vuole persistente
chi vuole memorizzare dati eventi su sd, poco utile col suo millis interno e scomodo prendere un clock esterno
chi vuole semplicemente avere una paginetta contenuta nello sketch senza troppe cose
ecc....

non è facile buttare giù qualcosa che accontenti tutti, bisognerebbe sapere quali sono i problemi riscontrati e soprattutto sapere quale progetto è più comune a tutti gli utenti e creare un modello standard
Quindi bisogna anche pubblicare qui ..... io vorrei che la mia ethernet facesse questo e quest'altro.......poi tirare le somme 

ciao



 

[Reply #43 on:]

per questo sono partito così a "basso livello" a raccontare come funzionano le cose, così dò gli strumenti per fare tutto ciò che necessitano. Certo si protrebbe affrontare ogni problema specificatamente, ma basta una minima variazione per dover ricominciare da capo.

Quindi meglio una piccola ma esauriente guida.

che completerò quando tornerò in italia, al momento mi viene difficile scrivere in italiano e ascoltare i conquilini che parlano in inglese senza mischiare le due cose

[Reply #44 on:]

Grazie a tutti! In particolare a Fabrizio per l'ottimo lavoro, naturalmente speriamo in aggiornamenti futuri.
@ Pablos: niente male quella "lista della spesa", in realtà all'inizio chiedevo ad ognuno di scrivere la propria esperienza, se portata a buon fine con successo, su un determinato scopo prefissato. Cioè se tu sei riuscito, p.es. a "inviare dati passando da Pachube", sarebbe bello che spiegassi tutta la procedura, materiali acquistati, problematiche risolte, composizione hw/sw definitiva. Se ognuno pubblicasse la propria esperienza in forma di tutorial, alla fine ne uscirebbe un lavoro tipo "Playground" dove, personalmente, finora sono riuscito solo una volta a trovare ciò che cercavo, eppure c'è praticamente tutto. Io mi sono offerto per fare un lavoro di riepilogo del materiale, anche se sarebbe meglio lo facesse uno che ha esperienza in questo settore, ma comunque alla fine una bella organizzazione tematica e ne uscirà un'opera d'arte. Lesto ha fatto un ottimo lavoro, e quanto sarà completo sarà perfetto, è un approfondimento teorico per chi vuole iniziare senza lanciarsi all'arrembaggio; il lavoro di Fabrizio aiuterà nella scleta d'acquisto, ma lui stesso dice di non averla comprata per ora; se chi l'ha fatto gli fornisse le proprie esperienze lui implementerebbe il suo tutorial, migliorandolo.
Ma se nessuno di voi che le state usando queste schede e ci state facendo anche lavori "seri" si prende la briga di trasmettere queste esperienze ovvio che non si arriverà mai a fare nulla.
Avete visto quanti nuovi post ogni settimana sul discorso ethernet? Basterebbe che per ognuno che va a buon fine qualcuno riepilogasse la procedura e sarebbe un nuovo argomento risolto.