Un linguaggio di programmazione in generale comprende un insieme di funzioni e istruzioni che ci permettono di interagire col computer. Quando vogliamo creare un programma capace di comunicare con un’altro programma tramite la rete, dobbiamo creare un insieme di funzioni che ci permette di utilizzare i servizi dei livelli inferiori per aprire e chiudere la connessione, inviare e ricevere dati ecc: abbiamo bisogno di utilizzare le così dette API (Application Programming Interface).
Ed è proprio in questo insieme di istruzioni, che rientrano le Socket
Socket
Una socket appare come un terminale o un file, ma non è un’entità fisica: è infatti una struttura dati (quindi astratta) creata dal programma applicativo.
Un processo client e un processo client possono comunicare tra di loro tramite due socket create da entrambi i lati della comunicazione.
Come vedremo negli articoli che stò preparando sui sistemi operativi, un Processo è un programma in esecuzione su di un host (indipendentemente client o server ovviamente, per come li abbiamo definiti quì).
Due processi possono comunicare fra di loro tramite schemi interprocesso che sono definiti dal Sistema Operativo: se vogliono però comunicare con processi su altri host, lo fanno tramite lo scambi di Messaggi.
Un processo client è colui che invia il primo messaggio diretto verso il processo Host che invece attende perennemente di essere contattato (forever alone :() – Anche nelle architetture P2P esistono processi client e server.
Un processo A su un host, per comunicare con un processo B su un’altro host, deve identificare il processo B. Per farlo, si utilizza l’ indirizzo IP: un indirizzo univoco a 32 bit.
Questo però, non è sufficiente: l’identificatore infatti, deve anche comprendere il numero di porta (questo riguarda il livello trasporto) a cui è associato il processo in esecuzione sull’ host.
Ad esempio, il server HTTP gira sulla porta 80 mentre il Mail Server sulla 25. I numeri di porta sono a 16 bit (quindi vanno dalla porta 0 alla 65535) e sono stati suddivisi dal IANA come segue:
- 0 non viene usato
- 1- 255 riservato per i processi noti (well known processes)
- 256-1023 Riservato per altri processi
- 1024-65535 Riservato per le applicazioni dell’ utente (es: skype).
Per avere una lista completa, è possibile consultare la RFC ( Request For Comment) numero 1700.
Nei programmi Client-Server, un client può inviare più richieste al server contemporaneamente ed il server può servire più utenti contemporaneamente.
Anche la socket lato client ha un indirizzo IP e una porta sorgente: Di solito per queste non viene scelta una well known port, ma la scelta della porta è a discrezione del Sistema Operativo.
Quindi, per stabilire una connessione, abbiamo bisogno di:
Lato client:
- Un indirizzo ip, il Sistema operativo lo riesce a trovare e lo fornisce
- Una porta, assegnata a discrezione dell’ OS e chiamata “porta effimera”
Lato server:
- Un indirizzo ip, il Sistema operativo lo riesce a trovare e lo fornisce
- Una porta, che varia asseconda dell’applicazione o dalla volontà del progettista
Ad esempio, L’indirizzo ip di google.it (trovabile aprendo un prompt dei comandi/shell e digitando “ping google.it“) è 173.194.35.55, la porta è HTTP quindi 80, provate quindi a visitare:
173.194.35.55:80
Col vostro browser. Il vostro indirizzo ip è trovabile sempre da linea di comando dando ifconfig o ipconfig (a seconda del sistema) mentre tramite netstat -n e possiamo trovare il numero di porta da cui il nostro browser si collega.
Quale servizio richiede l’ applicazione?
Rispondendo a questa domanda formulata nello scorso articolo, nella creazione della nostra applicazione ci sono alcune cose che dobbiamo considerare per scegliere l’architettura migliore.
1. Perdita di dati
L’applicazione può tollerare una perdita di dati? Per esempio, se stò guardando un film in streaming o parlando su skype, preferisco non sentire/vedere l’interlocutore per un’istante, piuttosto che mi si blocchi la conversazione per diversi secondi prima che mi arrivi il pacchetto andato perduto. In questo caso quindi, la perdita di dati è ammessa.
Ma se io mando una mail, o trasferisco un file, non sono assolutamente ammesse perdite di dati!
2. Throughtput
Alcune applicazioni necessitano di una certa ampiezza di banda per essere efficienti. Altre invece, chiamate “applicazioni elastiche”, si adattano con la banda disponibile. Un esempio del primo caso sono i giochi online, uno del secondo è il browser per internet.
3. Temporizzazione
Potremmo a volte aver bisogno di ritardi per rendere l’applicazione più realistica come i giochi online o video chiamate, mentre altre applicazioni, come la posta, non si interessano di temporizzazioni.
4. Sicurezza
Cifratura, sicurezza nell’integrità dei dati in arrivo, sicurezza della comunicazione.
[divider_top]
Riesci a pensare ad una applicazione come Skype che tipi di servizio ha bisogno?
Vediamo quindi, a livello di trasporto, i due servizi disponibili e che si occupano di gestire queste quattro cose.
Servizio TCP
Se scegliamo di utilizzare, a livello di trasporto, il servizio TCP dobbiamo considerare che:
- E’ Connection- Oriented (Orientato alla connessione): due end system per parlare fra di loro hanno bisogno di un setup della connessione.
- E’ affidabile: Siamo sempre sicuri che i nostri messaggi arrivano a destinazione.
- Controllo di flusso e di congestione: Evita di sovraccaricare il destinatario e strozza il processo d’invio quando la rete è congestionata.
Non offre: Temporizzazione, garanzie su ampiezza di banda minima, sicurezza (questa è però implementabile in alcuni modi che vedremo più avanti).
Servizio UDP
Se invece vogliamo utilizzare l’ UDP, ecco le sue caratteristiche:
- Non è Connection-Oriented: Non abbiamo bisogno di impostare la connessione prima di poter comunicare
- Non è affidabile: Funziona come il sistema postale. Abbiamo una pila di lettere, e le imbuchiamo. Alcune potrebbero arrivare prima di altre non seguendo l’ordine con cui le abbiamo imbucate: altre ancora potrebbero non arrivare mai.
Non offre: setup della connessione, affidabilità, controllo di flusso, controllo della congestione, temporizzazione né ampiezza di banda minima e sicurezza.
A differenza del TCP però, l’ UDP è molto più rapido e non sempre abbiamo bisogno dell’ affidabilità. Per esempio, immaginate di fare una video chiamata con skype: Se usassimo il protocollo TCP, l’immagine si bloccherà finchè non arriverà il pacchetto che è andato perso o che è in ritardo.
Con UDP invece, la perdita di un pacchetto si manifesta in un blocco immagine che dura un ‘istante.
Primitive di Sistema
Con questo termine si intende un’insieme minimo di funzioni che permettono di implementare un semplice servizio orientato alla connessione.
- LISTEN: Attesa bloccante di una connessione in arrivo
- CONNECT: Stabilisce una connessione con un pari in attesa
- RECEIVE: Attesa bloccante per un messaggio in arrivo
- SEND: Manda un messaggio al peer (pari)
- DISCONNECT: Termina una connessione
