Reti Lab

Web-server

Il server normalmente sta su una socket stream, cosa offre?

• Un canale doppio di I/O dove ogni lato del canale è un flusso di byte non
strutturato, sopra quello si può mettere un server http
La cosa bella della stream è : garantisce un servizio affidabile, inoltre non
essendo strutturata consente una strutturazione ad alto livello senza doversi
preoccupare della dimensione dei messaggi a basso livello.

Creazione socket stream

siamo a livello applicazione, sotto abbiamo il livello presentazione che si occupa

della crittografia, sotto ancora la sessione che si occupa della sincronizzazione
tra thread ecc…

Aprire un socket equivale ad aprire dei buffer che servono per leggere e scrivere
dalla socket

La bind serve per utilizzarre questi buffer, connette I

buffer a una porta logica del sottosistema di trasporto
TCP, ciò che parte da un processo per la rete passa dai
buffer e poi verso la porta stessa cosa in ricezione.

Listen, mantieni un numero chiamate pendenti quanto si

vogliono connettere al mio socket fino a un numero
massimo N, dopodichè scarta la chiamata.
index of
Accept, gil si passa il descrittore del client che si è
connesso (chiamata bloccante), quando dall ‘altra parte
un client si connette esce dall’ attesa e mi
restituisce un FD.

Se faccio una bind con 0, si attacca a tutte le porte

Quando arriva un client cosa succede? Manda un messaggio SYN, il messaggio arriva
al buffer, se non c’è ne sono altri il sistema operativo legge il messaggio e manda
indietro un messaggio SYN al client, inoltre viene creato un altra coppia di buffer
che sarà utilizzato per la comunicazione client server.

<Psorgente, IPSorgente, Pdestinazione, Ipdestinazione> quadrupla che identifica una

connessione TCP. Questa quadrupla viene utilizzata per identificare La coppia di
buffer destinata alla comunicazione.
Semplice Server TCP in C

NB: le porte sono libere sopra la 1024.

HTTP VS SERVER QUALUNQUE

Cambiano I messaggi a livello applicativo, possiamo costruirci un messaggio HTTP

utilizzando una stringa formattata nel seguente modo

È utili avere il target dell’host perchè non è detto che quando instauro una
comunicazione con l’host dialoghi direttamente con l’host finale, ma è possibile
che ci sia un proxy di mezzo e esso deve sapere a chi mandare il messaggio.
User Agent, serve per decidere come inviare il messaggio di risposta.
Connection, identifica il tipo di connessione: persistente o non persistente.
Quando termina l’ header abbiamo un carriege return e aggiuntivo
 Siamo liberi di
strutturare il body come
vogliamo(usare JSON o
xml)

Messaggio di risposta HTTP

Stato dell’utente

I web server sono stateless, ogni messaggio che viene inviato e ho ricevuto
risposta attraverso il socket, il web server non mantiene in memoria di ciò che gli
ha detto.

Mantenere la sessione per ogni client sarebbe molto costoso soprattutto se ci sono
errori.

Cookie

Stringa testuale che contine le informazioni per identificare il client, quando il

client entra gli si dà un cookie in questo modo se dovesse rientrare
automaticamente so le informazioni che lo riguardano. Per cui il concetto di
sessione è ricreata in questo modo, sopravvivendo addirittura al tempo di vita del
socket. Si può implementare la remote procedure call attraverso I cookies.

Esso viene messo in una linea dell’ header.

 Http server che
utilizzeremo.

Rispetto al modello publish/subscribe non inseriamo un messaggio dentro la coda di

messaggi di un thread che esegue il lavoro, ma inseriamo un puntatore a un metodo
che esegue quella cosa.

Le due tavole sono molto simili e sono chiamate tavole di instradamento.

I demoni vengono spenti automaticamente quando viene spento il programma.

Message Broker

Abbiamo delle thread che si interfacciano agli agenti remoti, immaginiamo di avere
un Publish thread in attesa su una porta, abbiamo un remote publisher che si
connette al publish thread locale e gli comunica il soggetto che vuole fare la
connessione, il quale sottoscriverà il soggetto nella subject table, quando
qualcosa viene pubblicato viene inviato alla thread che lo ha sottoscritto il quale
è connesso tramite TCP al soggetto. Queste operazioni sono svolte da mosquitto.
Subject mosquitto esistono diversi tipi di sottoscrizioni, e sono identificati dal
loro pathname assoluto nel subject tree es: B/+/x il simbolo # corrisponde a *
utile in fase di debugging.

Msqtt consente di definire un altra istanza di Msqtt connessa in bridging , quando

facciamo questa connessione, tutto ciò che viene pubblicato su un’ istanza, viene
trasmessa sull’ altra istanza.

Come si fa?

• Connection bridge-01
• address indirizzo a cui connettersi
• topic: # out 0(sottoscrive tutti I subject e si connette per pubblicare)
• topic: # in 0mosquitto client in java
Mentre nella macchina locale

• connectio bridge-01
• address indirizzo su cui gira mosquitto
• topic: # out b1/ “”
• topic: # in 0 “” b2/

Interfacciarsi a MSQTT

mosquitto_sub -h (nomehost)test.mosquitto.or -t ‘#’, sottoscrive tutti I subject

mosquitto_pub -t A/B -m “messaggio per chi sottoscrive” sottoscrive un publisher.
Fare due client, il publisher e il subscriber.