In questo articolo vediamo la differenza fra servizi e protocolli, e vediamo i tipi di Architetture di rete che è possibile incontrare.

Il concetto di Servizio non deve essere confuso col concetto di Protocollo. Come già abbiamo visto nel precedente articolo, col nome protocollo si intende una serie di convenzioni che un livello n utilizza per comunicare col livello n di un’altro dispositivo.

Un servizio invece, è un insieme di primitive offerte dal livello n che vengono sfruttate dal livello n+1 (lo strato superiore).

L’ incapsulamento (come, per associare il termine ad un altro campo dell’ informatica, nella OOP) è una tecnica potente che ci permette di offrire un servizio, farlo utilizzare da qualcuno ma senza fargli vedere i dettagli implementativi.

Questa suddivisione in layer, come già avevamo visto anche l’altra volta, ci permette una incredibile semplicità di design: Se per esempio per qualche motivo voglio cambiare un layer n, l’importante è che il nuovo modulo continui ad offrire i servizi allo strato superiore (anche se magari li implementa in maniera differente).

Se vogliamo trovare uno svantaggio a questa stratificazione , a volte potrebbe essere possibile che un livello n abbia bisogno di informazioni non reperibili dai livelli adiacenti.

Livello Applicazione

In cima a tutta la pila TCP/IP che abbiamo visto l’altra volta, troviamo il livello applicazione: questo livello offre, come gli altri, un servizio al layer superiore.

E quale sarà? Ma ovviamente l’utente!

Come abbiamo visto l’ altra volta due livelli n, a meno del livello fisico, pensano di essere connessi fisicamente fra di loro ma in verità la loro connessione è logica:  per comunicare devono prima passare per tutti i layer sottostanti fino a quello fisico.

Visto che il livello applicazione fornisce servizi all’ utente, è stato progettato in modo da offrire la possibilità di creare nuovi protocolli con estrema facilità e velocità, al giorno d’oggi non è possibile stabilire quanti protocolli esistano su questo livello (e pensa che, per esempio, a livello rete troviamo solo l’ IP).

Un protocollo progettato a livello n, come già detto, deve sfruttare i servizi offerti dal protocollo n-1.

Per creare una applicazione che sfrutti la rete (vedi per esempio bittorrent, skype, firefox eccetera) dobbiamo chiederci:

  1. Che architettura vuole sfruttare (le vedremo fra poco)?
  2. Come fanno a comunicare i processi fra di loro? (Prossima lezione)
  3. Che tipo di servizi richiede la connessione?(Prossima lezione)

Tipi di architetture

Esistono principalmente tre tipi di paradigmi:

  • Client–Server: per esempio la struttura di internet;
  • Peer–to–peer (o P2P per gli amici): per esempio Emule o Bittorrent;
  • Architetture ibride: per esempio Skype o i programmi di messaggistica.

Cominciamo a vedere il paradigma client-server che ci permetterà di capire di cosa stiamo parlando

Client- Server

Quando creiamo una applicazione di rete, dobbiamo chiederci: che architettura vuole sfruttare? O meglio, facciamo un esempio:

Vogliamo creare un programma sul computer A, che ci permette di collegarci al programma sul computer B e tramite l’invio di alcuni comandi, ci permetta di scaricare determinati files.

Ecco, questa è l’architettura di internet: abbiamo

  • un Client, colui che richiede il servizio
  • un Server, colui che fornisce il servizio.

Le differenze sono che il client (o meglio, il processo sulla macchina client) viene avviato solamente quando abbiamo bisogno del servizio (non è che lasciamo sempre aperto il browser) mentre il server (o meglio, il processo sulla macchina server) deve rimanere in perenne attesa di richieste da parte di un client (non è che invece Google ogni tanto lo troviamo offline).

Il client inoltre è colui che inizia la conversazione col server richiedendo un servizio, mentre il server è colui che risponde alla richiesta inviando informazioni che poi il client deve interpretare.

Esempi tipici sono il Web, la posta elettronica, FTP ed SSH.

Peer-To-Peer

Questo tipo di approccio è diventato famoso grazie all’avvento dei programmi di file sharing (quindi intorno al 2000 con Napster, papà di Emule): è comunque nato per venire incontro alla necessità di alcune applicazioni.

In questo tipo di paradigma, non esiste un client ed un server: peer infatti significa pari, perchè tutti i dispositivi a seconda del caso sono o client o server.

In questo modo il carico di comunicazione è distribuito, è un sistema scalabile e non c’è nessuna necessità di infrastrutture costose.

Gli svantaggi sono ovviamente di sicurezza, perchè è difficile da gestire, e Applicabilità perchè non tutte le applicazioni si prestano a questo paradigma.

Paradigma misto

Volendo, un’ applicazione può sfruttare entrambi i paradigmi visti in modo da sfruttare il meglio di entrambi. Un esempio sono i sistemi di messaggistica: Skype, Windows live (azz è sempre skype).
Vabbè, per esempio, Skype utilizza:

Il paradigma server-client per: Eseguire il login al nostro account, scaricare la lista dei nostri contatti, registrarci su Skype per dire ai nostri amici “ehi, sono online!”

Il paradigma p2p: Una volta che tu e un tuo amico vi siete loggati su skype, quando vuoi chiamarlo o scrivergli chiedi a Skype il suo indirizzo ip. Una volta richiesto, comincia la comunicazione in p2p.