4. Wireless Session Protocol (WSP)

Il livello Session (vedi figura 4.1), interfaccia direttamente il livello applicativo (WAE) ricoprendo lo stesso ruolo di HTTP 1.1 della architettura Internet;  i servizi offerti al superiore livello Application (WAE) sono orientati allo scambio dei contenuti in senso bidirezionale client/server. In particolare il livello WSP si fa carico di:

1. Stabilire e rilasciare in modo sistematico sessioni di comunicazione tra client e server.

2. Prendere accordi con l’entità di pari livello circa le funzionalità di protocollo da adottare utilizzando meccanismi di negoziazione (capability negotiation) simili a quelli visti in HTTP.

3. Scambiare dati tra client e server usando codifiche compatte.

4. Sospendere e riattivare le sessioni precedentemente aperte.

Fig 4.1 Stack  protocol  WAP

Inoltre, al livello compete la gestione dell’eventuale interruzione di transazioni in corso, la gestione delle Push information e la gestione della negoziazione delle caratteristiche di protocollo relative a sessioni multiple. Il livello WSP  funziona al di sopra del livello Transaction (WTP) per una serie di servizi connection oriented e direttamente sul livello Datagram (WDP) per un'altra serie di servizi connectionless oriented. La “sicurezza” del collegamento è demandata al livello opzionale WTLS.

WSP è di fatto un HTTP espresso in forma binaria compatta, forma imposta dalla ristrettezza di banda delle reti wireless e dalla limitata capacità di memoria dei terminali wireless. Infatti, come in HTTP gli  header usati in questo livello definiscono il tipo di dato, il set di caratteri, i linguaggi naturali componenti i frame etc, etc che caratterizzano le informazioni ipertestuali destinate da e per il livello Application.

Il ciclo di vita di una sessione non dipende dal livello inferiore Transaction (WTP) ma ha una sua durata indipendente e completamente autogestita; sono previste a tal proposito sospensioni di sessioni ovvero uno stato di sessione intermedio tra lo stato di apertura e chiusura di una sessione che può essere riabilitato in un secondo momento senza  ri-negoziare e ri-inizializzare la sessione in essere. Gli stati intermedi di sessione si rendono necessari nei protocolli dedicati alle reti wireless perché è fortemente probabile che durante transazioni in corso il client non sia temporaneamente raggiungibile a causa di rapsodiche mancanze della copertura radioelettrica offerta da parte della rete wireless utilizzata; la mancanza dei suddetti stati intermedi provocherebbe un inutile reimpiego di risorsa radioelettrica per ri-inizializzare il processo di apertura della sessione.

L'informazione Pull (ovvero un informazione chiesta dal client al server) viene gestita dal WSP con i medesimi meccanismi di Request e Respond di HTTP; dunque una richiesta del client si esaurisce con una associata risposta di servizio del server.
L'informazione Push (ovvero un informazione mandata spontaneamente dal server al client senza che quest'ultimo nè abbia fatto richiesta) viene gestita dal WSP in base a tre modalità d'invio:

• Confirmed data push con contesto di sessione eistente: ovvero la possibilità di fare push d'informazione ritornando conferma di ciò al server a patto che si sia già instaurata una sessione.

• Nonconfirmed data push con contesto di sessione esistente: ovvero come sopra ma senza conferma di push da client verso server.

• Nonconfirmed data push senza contesto di sessione esistente: ovvero un push d'informazione privo sia di sessione esistente che di conferma da inviare al server  (quindi completamente libero da ogni contesto).

La gestione della informazione Push assume così una modellizzazione dotata di estrema flessibilità. Si possono effettuare invii affidabili (reliable) utilizzando sia la prima che la seconda modalità a seconda se necessiti avere conferma o meno della avvenuta ricezione dell’informazione a destinazione. In questo caso il livello WSP si interfaccia con il livello WTP. La terza modalità offre un metodo assai veloce di destinazione della informazione seppur non affidabile non essendo lo stesso sottoposto al controllo di sessione. In questo ultimo caso il livello WSP si interfaccia direttamente con il livello WDP

Le primitive del livello WSP, ovvero i moduli di servizio offerti al livello Application, sono raggruppate in due macro classi: primitive connection oriented e primitive connectionless oriented. 

Le primitive connection oriented sono strutturate a seconda delle funzionalità che esse stesse offrono. Avremo primitive di tipo:

• Session Management: sono primitive in cui client e server si accordano sulle opzioni di protocollo disponibili e quindi da utilizzare nella sessione corrente. Il server può rifiutare il tentativo di connessione o eventualmente redirigere il client presso un altro server. Se il server accetta la connessione allora durante la costituzione della sessione il client ed il server si scambiano delle informazioni e negoziano dei parametri che si aspettano siano validi per tutta la durata della sessione. Sia il server che il client possono poi terminare la sessione.

• Method invocation: sono primitive che permettono al client di chiedere l’esecuzione di una operazione e la restituzione del risultato ad un server. Il client utilizza i metodi previsti da HTTP. 

• Exception Reporting: sono primitive che permettono al fornitore del servizio di notificare all’utente il verificarsi di eventi che non causano il cambiamento di stato di una sessione.

• Push: sono primitive in cui il server invia informazioni in modo spontaneo e asincrono senza che sia instaurata alcuna sessione.

• Confirmed Push: sono primitive come sopra ma con conferma inoltrata dal client e sessione instaurata.

• Session Resume: sono primitive orientate alla riattivazione di sessione aperte ma sospese.

Le primitive connectionless oriented offrono servizi non confermati (inoltre la comunicazione tra le entità può essere instabile) che possono essere usati per lo scambio di dati tra gli utenti del protocollo.

5. WTP