Lo stack TCP/IP di Microchip

Microchip è sicuramente molto famosa per via dei processori della serie PIC e dei suoi moduli software che distribuisce e di questi, certamente, lo stack TCP/IP è uno degli oggetti più interessanti.

Lo Stack TCP/IP di casa Microchip si compone di una suite di programmi e codice sorgente in grado di offrire servizi per applicazioni basate sul protocollo TCP/IP, ovvero HTTP Server, mail client con il protocollo SMTP e, successivamente, con SNMP. A questo proposito la tabella 2 pone in evidenza i diversi RFC applicabili. L’approccio di Microchip è davvero interessante, tanto da favorire la portabilità delle applicazioni scritte per differenti piattaforme. In effetti, lo stack è stato implementato ricorrendo ad una struttura di tipo modulare dove tutti i servizi sono definiti ad un alto livello di astrazione tale da poter essere abilitati o disabilitati a piacimento. La suite così definita da Microchip è particolarmente attenta alle risorse fisiche che un sistema embedded deve possedere; ovvero, lo stack richiede uno spazio minimo in termini di memoria (tabella 1) e in capacità di calcolo, grazie all’adozione di un sistema multitasking a cicli cooperativi.

LO STACK TCP/IP

Per protocollo TCP/IP, ovvero Transmission Control Protocol/Internet Protocol, non si intende solo il protocollo di trasmissione TCP ed il protocollo di rete IP, ma in realtà si vuole identificare una famiglia di protocolli (figura 1) comprendente tra l’altro l’UDP, l’ICMP, l’ARP e il RARP.

Figura 1: suite protocollo TCP-IP.

La maggior parte delle realizzazioni di rete disponibili in commercio rispecchiano l’architettura così definita attraverso il modello di riferimento (figura 2) e i differenti moduli software utilizzati dividono la loro funzionalità in base al livello di riferimento sovrapposto: ecco perché spesso si intende associare il nome di pila o stack.

Figura 2: protocollo TCP IP.

Non è superfluo precisare che il modello di riferimento non include la sessione applicazione, ovvero i programmi che gestiscono la posta elettronica o il trasferimento dei file, l’emulazione di terminale remota o la gestione e la navigazione in rete. La pila TCP/IP è organizzata, in modo concettuale, in quattro livelli, oltre al supporto fisico vero e proprio (figura 3 e 4).

Figura 3: I livelli considerati.

Figura 4: le corrispondenze.

Tabella 1: memoria utilizzata.

Tabella 2: RFC Applicabili.

Lo strato applicativo si dispone a livello più alto ed è utilizzato dall’utente per invocare i programmi applicativi che permettono di accedere ai servizi disponibili: il livello applicativo identifica, in sostanza, le applicazioni utilizzate e definite dall’utente. Un programma applicativo interagisce con uno dei protocolli di livello trasporto per inviare o ricevere dati e li passa al livello trasporto nella forma richiesta. Il successivo strato è identificato dal Transport Layer che permette la connessione in rete fra due utenti, ovvero assicura la comunicazione tra un livello applicativo ed un altro: una comunicazione di questo tipo è spesso detta end-to-end. È in questo strato che si divide il flusso delle informazioni in pacchetti, con un’articolazione tale che, oltre a identificare ogni pacchetto, si associa anche l’indirizzo di destinazione e lo si manda allo strato sottostante. Il livello di trasporto deve accettare dati da molti utenti contemporaneamente e, viceversa, deve smistare i pacchetti che gli arrivano ai vari specifici programmi. In effetti, per assicurare una corretta comunicazione, è necessario utilizzare delle apposite porte. Lo strato software che sovrintende a questa gestione aggiunge, ad ogni pacchetto, alcuni bit che servono per codificare le porte di ingresso con la destinazione: il livello di trasporto può regolare il flusso di informazioni e, nel caso del TCP, può fornire un trasporto affidabile assicurando che i dati giungano a destinazione senza errori e nella corretta sequenza mediante un meccanismo di acknowledgement e ritrasmissione. Lo strato inferiore è l’Internet Layer. Questo particolare strato gestisce la comunicazione tra una macchina ed un’altra attraverso la gestione di una richiesta di spedizione di un pacchetto da un livello di trasporto insieme all’identificazione della macchina alla quale il pacchetto deve essere inviato. L’IP, o Internet Protocol, crea il data gramma di base della rete, sostanzialmente, riceve e trasferisce senza garanzie i pacchetti, che gli arrivano dal livello superiore, verso la macchina destinataria. Questo strato accetta i pacchetti TCP, li spezzetta, se necessario, e li incapsula nei datagramma di base IP. Non solo, riempie gli header necessari ed usa l’algoritmo di routing per decidere a chi deve mandare i dati, in particolare se si tratta di un caso di routing diretto o di routing indiretto. Il livello Internet gestisce anche i datagrammi in ingresso, verifica la loro validità ed usa l’algoritmo di routing per decidere se il datagramma deve essere inoltrato o processato localmente; in quest’ultimo caso il software elimina l’header del datagramma e sceglie quale protocollo di trasporto gestirà il pacchetto. Non solo, questo livello gestisce integralmente i messaggi ICMP in ingresso e uscita. Infine, l’ultimo strato, Network Interface Layer, costituisce l’interfaccia di rete che accetta il datagramma IP e lo trasmette, previo incapsularlo in appositi frame, sull’hardware (il cavo) utilizzando un transceiver. In base alla tipologia architetturale può anche succedere che il pacchetto può attraversare altre macchine intermedie (router) prima di giungere alla sua destinazione: in questo caso risultano coinvolti solo i due strati più bassi dell’interfaccia di rete e del datagramma base IP. Un’architettura di questo tipo assicura maggiore flessibilità all’intero sistema: in questo modo diventa possibile sostituire una parte senza disturbare necessariamente le altre. In un’implementazione di questo tipo ogni livello accede unicamente a servizi del livello sottostante. Per questa ragione molti livelli del modello ISO/OSI non si attivano unicamente quando un servizio viene richiesto da un livello superiore. Microchip per realizzare il suo stack non ha trascurato nessun dettaglio allo scopo di garantire la sua compatibilità anche verso microcontrollori a 8 bit con poche risorse di memoria. Non solo, Microchip ha anche pensato di realizzare la sua applicazione tenendo presente l’esigenza di disporre di un sistema asincrono per meglio coordinare le operazioni richieste. In effetti, il costruttore, pur evitando di implementare ed appesantire il sistema, offre l’intero stack senza un multitasking, assicurando, però, al contempo, una netta separazione tra l’applicazione principale e lo stack stesso. A questo proposito Microchip ha realizzato il suo multitasking di tipo cooperativo. In un sistema di questo tipo i task presenti non sono eseguiti contemporaneamente, ma sono posti in esecuzione in modo sequenziale attraverso il modulo StackTask e a questo proposito il listato 2 mostra un possibile utilizzo. Ad ogni ciclo Stacktask verifica se esistono pacchetti da elaborare indirizzandoli verso la funzionalità appropriata.

// =======================================================================
// Application Options
// =======================================================================
/* Application Level Module Selection
* Uncomment or comment the following lines to enable or
* disabled the following high-level application modules.
*/
#define STACK_USE_UART // Application demo using UART for IP address display and stack configuration
#define STACK_USE_UART2TCP_BRIDGE // UART to TCP Bridge application example
//#define STACK_USE_IP_GLEANING
#define STACK_USE_ICMP_SERVER // Ping query and response capability
#define STACK_USE_ICMP_CLIENT // Ping transmission capability
//#define STACK_USE_HTTP_SERVER // Old HTTP server
#define STACK_USE_HTTP2_SERVER // New HTTP server with POST, Cookies, Authentication, etc.
//#define STACK_USE_SSL_SERVER // SSL server socket support (Requires SW300052)
//#define STACK_USE_SSL_CLIENT // SSL client socket support (Requires SW300052)
#define STACK_USE_DHCP_CLIENT // Dynamic Host Configuration Protocol client for obtaining IP address and other parameters
#define STACK_USE_DHCP_SERVER // Single host DHCP server
//#define STACK_USE_FTP_SERVER // File Transfer Protocol (old)
#define STACK_USE_SMTP_CLIENT // Simple Mail Transfer Protocol for sending email
#define STACK_USE_SNMP_SERVER // Simple Network Management Protocol v2C Community Agent
//#define STACK_USE_TFTP_CLIENT // Trivial File Transfer Protocol client
#define STACK_USE_GENERIC_TCP_CLIENT_EXAMPLE // HTTP Client example in GenericTCPClient.c
#define STACK_USE_GENERIC_TCP_SERVER_EXAMPLE // ToUpper server example in GenericTCPServer.c
#define STACK_USE_TELNET_SERVER // Telnet server
#define STACK_USE_ANNOUNCE // Microchip Embedded Ethernet Device Discoverer server/client
#define STACK_USE_DNS // Domain Name Service Client for resolving hostname strings to IP addresses
#define STACK_USE_NBNS // NetBIOS Name Service Server for repsonding to NBNS hostname broadcast queries
#define STACK_USE_REBOOT_SERVER // Module for resetting this PIC remotely. Primarily useful for a Bootloader.
#define STACK_USE_SNTP_CLIENT // Simple Network Time Protocol for obtaining current date/time from Internet
//#define STACK_USE_UDP_PERFORMANCE_TEST // Module for testing UDP TX performance characteristics. NOTE: Enabling this will cause a
// huge amount of UDP broadcast packets to flood your network on the discard port.
// Use care when enabling this on production networks, especially with VPNs
// (could tunnel broadcast traffic across a limited bandwidth connection).
#define STACK_USE_TCP_PERFORMANCE_TEST // Module for testing TCP TX performance characteristics
#define STACK_USE_DYNAMICDNS_CLIENT // Dynamic DNS client updater module
#define STACK_USE_BERKELEY_API // Berekely Sockets APIs are available

Listato 1 – Direttive di sistema

while(1)
{
// Blink LED0 (right most one) every second.
if(TickGet() t >= TICK_SECOND/2ul)
{
t = TickGet();
LED0_IO ^= 1;
}
// This task performs normal stack task including checking
// for incoming packet, type of packet and calling
// appropriate stack entity to process it.
StackTask();
// This tasks invokes each of the core stack application tasks
StackApplications();
// Process application specific tasks here.
// For this demo app, this will include the Generic TCP
// client and servers, and the SNMP, Ping, and SNMP Trap
// demos. Following that, we will process any IO from
// the inputs on the board itself.
// Any custom modules or processing you need to do should
// go here.
#if defined(STACK_USE_GENERIC_TCP_CLIENT_EXAMPLE)
GenericTCPClient();
#endif
#if defined(STACK_USE_GENERIC_TCP_SERVER_EXAMPLE)
GenericTCPServer();
#endif
#if defined(STACK_USE_ICMP_CLIENT)
PingDemo();
#endif
#if defined(STACK_USE_SNMP_SERVER) && !defined(SNMP_TRAP_DISABLED)
SNMPTrapDemo();
if(gSendTrapFlag)
SNMPSendTrap();
#endif
ProcessIO();
// If the local IP address has changed (ex: due to DHCP lease change)
// write the new IP address to the LCD display
if(dwLastIP != AppConfig.MyIPAddr.Val)
{
dwLastIP = AppConfig.MyIPAddr.Val;
DisplayIPValue(AppConfig.MyIPAddr);
}
}

Listato 2 – esempio multitasking di tipo cooperative

LO STACK MICROCHIP

Lo stack di Microchip risulta estremamente flessibile e assicura la presenza di diversi servizi quali un server HTTP, server FTP, un DCHP e IP Gleaning. Il server HTTP risulta incluso nella pila Microchip e coesiste con l’applicazione principale dell’utente. Il server stesso è implementato nel file http.c e manifesta diverse limitazioni rispetto ad un’implementazione completa del protocollo HTTP. Microchip permette di dimensionare la propria applicazione aggiungendo o togliendo funzionalità. In linea di massima, è possibile senz’altro affermare che l’implementazione classica di Microchip prevede la presenza di connessioni HTTP multiple, di un rudimentale file system (figura 5) realizzato attraverso MPFS, supporta la memorizzazione di pagine Web nella sua memoria flash di programma interna o nella memoria seriale esterna EEPROM, permette, attraverso un apposito programma, la creazione di immagini MPFS da una directory assegnata, supporta il metodo HTTP GET e POST, supporta una CGI (Common Gateway Interface) per invocare funzioni predefinite dal browser remoto e, infine, permette la generazione dinamica del contenuto delle pagine web.

Figura 5: il file system presente

Il server Microchip è composto da un MPFS Image Builder, MPFS Access Library, MPFS Download Routine e un HTTP Server Task. Il server utilizza il file index.htm come pagina Web di default: è questa la pagina che viene visualizzata quando un client remoto, browser, accede al server Microchip attraverso il suo indirizzo IP o solo nome del dominio. Ad ogni modo, è possibile modificare il nome della pagina intervenendo sul simbolo HTTP_DEFAULT_FILE_STRING presente nel file http.c. Il server Microchip permette la gestione dei file con estensioni txt, htm, gif, cgi, jpg, cla e wav.

CONFIGURAZIONE SERVIZI

Microchip, allo scopo di assicurare la portabilità del suo stack, ha deciso di inserire all’interno di ogni file sorgente le direttive del preprocessore C che servono per abilitare, disabilitare o impostare un particolare parametro e, di conseguenza, selezionare una particolare configurazione. L’utilizzatore deve agire su questi parametri per inserire o togliere moduli funzionali e, per ragioni di comodità, sono state inserire in un file comune StackTsk.h (figura 6).

Figura 6: definizioni di sistema.

Stesso discorso per configurare i servizi che si intendono utilizzare a livello dell’applicazione, anche in questo caso occorre intervenire attraverso la direttiva #define associata che si trova nel file TCPIPConfig.h, a questo proposito la figura 6 mostra un estratto delle varie informazioni selezionabili. Il file contiene diverse direttive quali ICMP_SERVER e ICMP_CLIENT (Internet Control Message Protocol) anche se non sono necessari per il funzionamento di un server http, questi potrebbero risultare utili in fase di debug. La definizione di HTTP2_SERVER identifica la presenza del protocollo http (HyperText Transfer Protocol), mentre AUTO_IP, DHCP_CLIENT e DHCP_SERVER non sono strettamente necessari ma abilitano il Dynamic Host Configuration Protocol e l’auto-assegnazione dell’indirizzo IP: in questo modo è più facile inserire un dispositivo in una rete di computer. Stesso discorso per DNS e NBNS Domain Name Service e NetBIOS Name Service che permettono di interrogare il dispositivo posto in una rete di computer, senza conoscerne l’indirizzo IP, ma digitando nella barra degli indirizzi del browser un nome proprio definito in fase di programmazione. La direttiva REBOOT_SERVER identifica il servizio di riavvio da remoto del microcontrollore e diventa necessario a seguito di un aggiornamento remoto dell’immagine mpfs2 caricata sul dispositivo. Il servizio SNTP_CLIENT, ovvero Simple Network Time Protocol, permette al dispositivo di ottenere data e ora. Lo stack di casa Microchip utilizza anche le linee seriali per la fase di debug, ovvero UART e UART2TCP_BRIDGE. In effetti, la linea seriale è utilizzata per le operazioni di debug della macchina a stati. La definizione HTTP_SERVER individua la prima versione del protocollo HyperText Transfer Protocol lato server ed è estremamente limitata nelle sue funzionalità. Lo stack di Microchip offre anche diversi servizi come, ad esempio, SSL_SERVER e SSL_CLIENT. Il Secure Sockets Layer (SSL) è un protocollo crittografico per garantire la sicurezza delle comunicazioni sulla rete. Tali servizi non sono comunque indispensabili per la realizzazione di uno stack minimale. Non solo, il costruttore permette anche di inserire diverse applicazioni che sfruttano lo stack proprietario vale a dire con SMTP_CLIENT (Simple Mail Transfer Protocol) si seleziona la gestione e l’invio delle email dal dispositivo e il TELNET_SERVER, TErminaL NETwork, è il protocollo di rete utilizzato per fornire una comunicazione bidirezionale, testuale, con il dispositivo fino ad arrivare al Simple Network Management Protocol. Tutto questo grazie anche all'ausilio di uno starter kit Ethernet (vedi figura 7).