GSMWORLD.it



WAP
Home

Introduzione
Cos'é Wap?
Il WAP Forum
Perché Wap?
Architettura
WAP Gateway
WAP e Web server
Sicurezza
Stack WAP
      - WAE
      - WSP
      - WTP
      - WTLS
      - WDP

Configurazione
FAQ
Glossario

WML
TUTORIAL
Indice
Cos'é il WML?
La sintassi
Formattazione
Il primo deck
Tag 'DO'
Link
Template e timer
Immagini
Variabili
Un deck completo
Form e input
Form e select
WAP browser
I nostri consigli

Risorse/Emulatori
Risorse/Toolkit

GSMWORLD
Home
Tecnologia
News
Ricerca
Glossario
Contattaci


Ricerca
Ricerca un termine
in GSMWORLD:



webstat
GSMWORLD.it

WAP: il futuro nel telefonino

Lo stack WAP

 

WIRELESS SESSION PROTOCOL (WSP)

A cura di: Pettisani Diego e Ullo Antonio
Coordinamento: Prof. Alfredo De Santis
Sistemi di elaborazione dell'informazione (Sicurezza su Reti)
Università di Salerno - Anno Acc.1999-2000

Il livello Session (vedi figura seguente), interfaccia direttamente il livello applicativo (WAE) ricoprendo lo stesso ruolo di HTTP 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.


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: 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.

Stampa questa pagina






GSMWORLD...viaggio nel mondo del GSM...
Copyright © Marcello Scatà 1997-2002 - Ultima modifica domenica 7 novembre 2004
Execution time 9 ms