La comunicazione client server nei del sistemi distribuiti

Table of Contents

Funzionamento di una comunicazione client-server
Scrivere un semplice server udp

La comunicazione client-server rappresenta uno dei modi fondamentali di interazione tra i nodi di un sistema informatico. Questo tipo di comunicazione consente ai nodi di connettersi e di scambiare informazioni in maniera efficiente e affidabile.

Nel contesto della comunicazione client-server, un nodo agisce come cliente e un altro come server. Il cliente inizierà la comunicazione richiedendo un servizio o una risorsa specifica al server, che a sua volta elaborerà la richiesta e invierà una risposta appropriata. Questo scambio di messaggi avviene secondo regole e protocolli predefiniti.

La connessione tra il client e il server può avvenire attraverso vari protocolli di trasporto. I protocolli di livello 4, come TCP (Transmission Control Protocol) e UDP (User Datagram Protocol), sono comunemente utilizzati per garantire una comunicazione affidabile o una trasmissione veloce e leggera dei dati, rispettivamente. Tuttavia, in alcuni contesti specifici, possono essere adottati protocolli di trasporto a livello applicativo. Un esempio notevole è l’utilizzo di HTTP (Hypertext Transfer Protocol) nei servizi web, in cui le pagine web possono scambiare dati con un server web mediante richieste e risposte basate su HTTP.

Questa architettura client-server è ampiamente diffusa e utilizzata in molti scenari, come il World Wide Web, i servizi cloud, le applicazioni mobile, i giochi online e molto altro. La comunicazione client-server ha reso possibile lo sviluppo di sistemi complessi, distribuiti e interconnessi, consentendo ai dispositivi e alle applicazioni di collaborare e scambiare dati in modo coordinato e efficace.

Funzionamento di una comunicazione client-server

Ecco un diagramma che rappresenta il flusso di comunicazione tra un client e un server, iniziando dalla connessione, passando per la richiesta, l’elaborazione e la risposta, e terminando con una disconnessione opzionale. Questi passaggi sono essenziali per la comunicazione client-server e vengono utilizzati in molte applicazioni e protocolli.

Loading graph...

Immagina di essere coinvolto in un dialogo con un server remoto tramite un’applicazione client. Nel diagramma, il partecipante “Client” rappresenta te come utente o il dispositivo da cui stai interagendo con il server. Il partecipante “Server” indica il server remoto con cui desideri comunicare.

Il primo passo del processo è la connessione. Il client stabilisce una connessione con il server, creando un canale di comunicazione dedicato. Questo passaggio è spesso necessario per stabilire una connessione sicura e affidabile, in particolare quando si utilizzano protocolli come TCP.

Una volta stabilita la connessione, il client invia una richiesta al server. La richiesta contiene informazioni su ciò che desideri ottenere o fare tramite il server. Potrebbe essere una richiesta di dati, l’esecuzione di un’operazione specifica o l’accesso a una risorsa particolare.

Il server riceve la richiesta dal client e passa alla fase di elaborazione. Durante questa fase, il server analizza la richiesta e determina cosa deve fare per soddisfarla. Può coinvolgere l’accesso a database, il calcolo di risultati, l’elaborazione di logiche specifiche dell’applicazione o l’esecuzione di altre operazioni necessarie per fornire una risposta appropriata.

Una volta completata l’elaborazione, il server genera una risposta che contiene i risultati della richiesta o informazioni pertinenti. La risposta viene quindi inviata al client attraverso il canale di comunicazione precedentemente stabilito. Il client riceve la risposta e può elaborarla ulteriormente o visualizzarla all’utente finale.

Infine, il diagramma include anche la possibilità di una disconnessione opzionale. Dopo aver completato la comunicazione, il client e il server possono decidere di terminare la connessione. Questo passaggio è facoltativo e dipende dalle esigenze dell’applicazione o del protocollo utilizzato. La disconnessione può avvenire attraverso un’operazione di chiusura della connessione, che consente al client e al server di liberare le risorse associate e interrompere la comunicazione.

Come funziona un server TCP

Il funzionamento di un server tcp può essere sintetizzato con il diagramma seguente:

Loading graph...

Nel diagramma, il nodo “Start” rappresenta l’inizio del processo del server, mentre il nodo “Stop” indica la conclusione. Il nodo “Inizializzazione” rappresenta il passaggio di inizializzare il server.

Dopo l’inizializzazione, il server passa al nodo “Creazione socket” per creare un socket per la comunicazione. Successivamente, nel nodo “Set opzioni socket”, vengono impostate le opzioni specifiche del socket, come il riutilizzo dell’indirizzo e altre configurazioni.

Il server procede quindi al nodo “Bind indirizzo IP e porta” per assegnare un indirizzo IP e una porta al socket. Nel nodo “Ascolto connessioni in entrata”, il socket inizia ad accettare connessioni in arrivo.

Nel flusso principale, il server passa al nodo “Accettazione connessione”, dove attende e accetta una connessione in arrivo tramite la chiamata “accept”. All’interno di questo nodo, viene creato un nuovo socket per la comunicazione con il client.

Una volta stabilita la connessione, il server passa al nodo “Ricezione richiesta”, dove riceve la richiesta inviata dal client tramite la chiamata “recv”. La richiesta viene quindi passata al nodo “Gestisci richiesta” all’interno del sottografo “Elaborazione” per validare i dati e eseguire le operazioni necessarie.

Dopo aver elaborato la richiesta, il server passa al nodo “Generazione risposta”, dove viene generata la risposta desiderata. Successivamente, la risposta viene inviata al client nel nodo “Invio risposta” attraverso la chiamata “send”.

Dopo l’invio della risposta, il server verifica nel nodo “Controllo chiusura” se è necessario chiudere la connessione. Se la connessione deve essere chiusa, viene eseguita la chiamata “close” nel nodo “Chiusura connessione” per terminare la comunicazione con il client.

A questo punto, il server ritorna al nodo “Fine elaborazione” per concludere l’elaborazione della richiesta. Successivamente, nel nodo “Altre richieste?”, il server verifica se sono presenti ulteriori richieste da gestire. Se ci sono altre richieste, il flusso torna al nodo “Ricezione richiesta” per continuare il processo. Altrimenti, il server raggiunge il nodo “Stop” per concludere il suo funzionamento.

Il sottografo “Socket” rappresenta le diverse funzioni coinvolte nella gestione dei socket, come la configurazione delle opzioni del socket, il binding dell’indirizzo IP e della porta, l’ascolto delle connessioni in entrata e la connessione a un indirizzo IP e una porta specifici.

Il sottografo “Elaborazione” rappresenta le operazioni di validazione dei dati e l’esecuzione delle operazioni richieste all’interno della fase di elaborazione della richiesta. Questo sottografo può essere espanso con ulteriori nodi e funzioni specifiche a seconda delle esigenze del server.

Come funziona un server UDP

Nel caso di un server che utilizza UDP come protocollo di trasporto, il funzionamento risulta essere più semplice rispetto ad altri protocolli, come TCP, poiché la comunicazione avviene attraverso l’invio e la ricezione di datagrammi indipendenti. A differenza di TCP, che fornisce un flusso di dati affidabile e orientato alla connessione, UDP si basa su un modello di comunicazione senza connessione, in cui ogni datagramma viene trattato singolarmente e senza alcuna garanzia di consegna o ordine.

Questa caratteristica di UDP rende il funzionamento del server più diretto e snello. Ogni datagramma inviato dal client viene ricevuto e elaborato separatamente, senza la necessità di mantenere una connessione persistente. Questo permette al server di dedicare meno risorse alla gestione delle connessioni e all’elaborazione del flusso di dati.

Tuttavia, la semplicità del funzionamento di un server UDP comporta anche alcune sfide. Poiché UDP non offre un meccanismo di controllo dell’affidabilità e del flusso dei dati, è compito del server gestire eventuali perdite di datagrammi, ritrasmissioni o problemi di ordine dei pacchetti. Inoltre, il server deve essere progettato per gestire eventuali congestioni di rete o problemi di latenza che possono influire sulla consegna dei datagrammi.

Nonostante queste sfide, l’utilizzo di UDP può essere vantaggioso in determinati scenari in cui la velocità e la leggerezza della comunicazione sono prioritari rispetto alla garanzia di consegna o all’ordinamento dei dati. Ad esempio, nei sistemi di streaming multimediale o nelle applicazioni in tempo reale, UDP può essere preferito per la sua capacità di fornire una comunicazione più rapida e reattiva.

Loading graph...

Dopo l’inizializzazione, il server passa al nodo “Creazione socket” per creare un socket UDP per la comunicazione. Successivamente, nel nodo “Binding”, il server assegna un indirizzo IP e una porta al socket.

Il server quindi si sposta al nodo “Ascolto”, dove rimane in ascolto di datagrammi UDP in arrivo. Nel nodo “Ricezione datagramma”, il server attende la ricezione di un datagramma tramite la chiamata “recvfrom”.

Una volta ricevuto un datagramma, il server passa al nodo “Elaborazione datagramma”, dove esegue le operazioni necessarie per elaborare i dati contenuti nel datagramma.

Successivamente, il server passa al nodo “Generazione risposta”, dove genera la risposta desiderata in base all’elaborazione dei dati. La risposta viene quindi inviata al mittente del datagramma nel nodo “Invio risposta” attraverso la chiamata “sendto”.

Dopo aver inviato la risposta, il server può passare al nodo “Controllo chiusura” per verificare eventuali condizioni che richiedono la terminazione del processo. In caso contrario, il flusso ritorna al nodo “Ricezione datagramma” per continuare l’ascolto di ulteriori datagrammi.

Il flusso del server UDP si ripete finché non si verifica una condizione di chiusura, momento in cui il server raggiunge il nodo “Stop” per concludere il suo funzionamento.

Server che utilizzando protocolli applicativi come protocolli di trasporto

Ecco il diagramma che rappresenta il funzionamento di un server che utilizza HTTP come protocollo di trasporto:

Loading graph...

Dopo l’inizializzazione, il server passa al nodo “Creazione socket” per creare un socket per la comunicazione. Successivamente, nel nodo “Binding”, il server assegna un indirizzo IP e una porta al socket.

Il server quindi si sposta al nodo “Ascolto”, dove rimane in ascolto di richieste HTTP in arrivo. Nel nodo “Ricezione richiesta HTTP”, il server attende la ricezione di una richiesta HTTP tramite la chiamata “recv”.

Una volta ricevuta una richiesta HTTP, il server passa al nodo “Elaborazione richiesta”, dove esegue le operazioni necessarie per interpretare e comprendere la richiesta del client.

Successivamente, il server passa al nodo “Generazione risposta”, dove genera la risposta desiderata in base all’elaborazione della richiesta. La risposta viene quindi inviata al client nel nodo “Invio risposta HTTP” attraverso la chiamata “send”.

Dopo aver inviato la risposta, il server può passare al nodo “Controllo chiusura” per verificare eventuali condizioni che richiedono la terminazione del processo. In caso contrario, il flusso ritorna al nodo “Ricezione richiesta HTTP” per continuare l’ascolto di ulteriori richieste HTTP.

Il flusso del server HTTP si ripete finché non si verifica una condizione di chiusura, momento in cui il server raggiunge il nodo “Stop” per concludere il suo funzionamento.

Quale tipologia di protocollo di trasporto utilizzare?

Nella scelta del tipo di comunicazione come trasporto in una comunicazione client-server, ci sono diverse variabili da valutare per determinare quale protocollo soddisfa al meglio le esigenze specifiche dell’applicazione. Le principali variabili includono:

Affidabilità: Se l’affidabilità dei dati è fondamentale, il protocollo TCP è generalmente preferito. TCP garantisce la consegna dei dati senza errori, il controllo di flusso e il controllo della congestione. Invece, UDP non offre garanzie di affidabilità intrinseca e può perdere pacchetti o consegnarli fuori sequenza.
Velocità: Se la velocità è una priorità e l’affidabilità può essere sacrificata, UDP potrebbe essere la scelta appropriata. Poiché UDP non ha il sovraccarico aggiuntivo del controllo di flusso e del controllo della congestione di TCP, è generalmente più veloce. Tuttavia, è importante considerare che l’assenza di meccanismi di correzione degli errori potrebbe richiedere un’apposita gestione nel codice dell’applicazione.
Latenza: Se la latenza è critica, UDP potrebbe essere preferibile. TCP ha meccanismi di controllo che garantiscono l’affidabilità dei dati, ma possono introdurre ritardi aggiuntivi nel trasferimento dei dati. UDP, al contrario, riduce la latenza ma può causare la perdita o l’arrivo fuori sequenza dei pacchetti.
Carico di rete: Se l’applicazione prevede un elevato volume di dati o una larga distribuzione geografica dei client, la scelta del protocollo deve considerare il carico di rete. TCP gestisce meglio il carico di rete grazie ai suoi meccanismi di controllo del flusso e della congestione, mentre UDP potrebbe generare più traffico a causa della sua natura senza connessione.
Tipologia di dati: Il tipo di dati trasmessi può influenzare la scelta del protocollo. Ad esempio, se si tratta di dati di streaming multimediale o di applicazioni in tempo reale che richiedono una bassa latenza, UDP potrebbe essere più adatto. Al contrario, se i dati richiedono integrità e precisione, come nel caso di transazioni finanziarie, TCP potrebbe essere la scelta migliore.
Complessità dell’implementazione: UDP è generalmente più semplice da implementare rispetto a TCP, che richiede gestione della connessione e meccanismi di controllo aggiuntivi. Se l’applicazione richiede una semplicità di implementazione o ha risorse limitate, UDP potrebbe essere preferibile.

È importante valutare attentamente queste variabili e comprendere le esigenze specifiche dell’applicazione per fare una scelta informata tra TCP, UDP o altri protocolli a livello di comunicazione disponibili.

Scrivere un semplice server udp

Come visto prima un server UDP si basa sul concetto di datagramma. Ecco il codice di un semplice server UDP scritto in python che ritorna al client un messaggio con l’ora corrente.

import socket
import time

# Configurazione del server
IP = "127.0.0.1"  # Indirizzo IP del server
PORT = 12345  # Porta del server

# Creazione del socket UDP
server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

# Binding dell'indirizzo IP e della porta al socket
server_socket.bind((IP, PORT))

print("Server avviato e in ascolto...")

while True:
    # Ricezione del messaggio dal client e dell'indirizzo del client
    data, client_address = server_socket.recvfrom(1024)

    # Generazione del messaggio di risposta contenente l'ora corrente
    current_time = time.ctime(time.time())
    response_message = f"Ora corrente: {current_time}"

    # Invio del messaggio di risposta al client
    server_socket.sendto(response_message.encode(), client_address)