Costruire una chat per Silverlight con il PollingDuplexHttpBinding

PollingDuplexHttpBinding under the hood

Sebbene l'implementazione in Silverlight 2.0 non sia facile e completa come lo è nei normali applicativi WCF client/server, tutto è fatto in modo che il codice lato server pensi di inviare al canale immediatamente i messaggi, mentre che il client li riceva in asincrono non appena uno è disponibile.

In realtà ciò che avviene a livello di trasporto HTTP è un continuo (polling) richiedere al server se c'è qualcosa di nuovo. Quando si instaura una sessione, mediante SignIn nell'esempio della chat, il client invia tra le altre cose un session id. Dal momento in cui poi si chiama BeginReceive, il binding effettua una richiesta al server, simile a questa:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 
  <s:Body> 
    <wsmc:MakeConnection xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702"> 
      <wsmc:Address>http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=9b3079ea-8bca-4992-ba9b-046481af3911</wsmc:Address> 
    </wsmc:MakeConnection> 
  </s:Body> 
</s:Envelope>

Il server tiene in carica la richiesta per un periodo determinato (proprietà ServerPollTimeout del binding server) dove in quel lasso di tempo, non appena è disponibile, restituisce il messaggio in coda. Altrimenti tronca la connessione e il client riprova immediatamente a fare una nuova connessione sul server, in modo ciclico. Il callback dell'EndReceive viene comunque invocato solo quando al tentativo di connessione, il server risponde con un messaggio.

E' importante quindi tarare bene la proprietà ServerPollTimeout, perché tempi bassi permettono di avere messaggi più prossimi al real time, ma viceversa intasano client e server di continue connessioni HTTP. La proprietà InactivityTimeout permette invece di stabilire dopo quanto tempo la sessione scade a fronte di una mancanza di inattività da parte del client.

Lato applicativo Silverlight si possono invece impostare i timeout per le connessioni HTTP di ricezione e invio dei messaggi. Il primo (ReceiveTimeout) dovrebbe essere maggiore o almeno uguale al ServerPollTimeout, mentre il secondo (SendTimeout) può mantenere tempi bassi, poiché in genere deve ricevere immediatamente una risposta dal servizio.

Conclusioni

Il PollingDuplexHttpBinding è un primo tentativo per permettere di consumare servizi duplex anche attraverso Silverlight. In questo articolo si è visto come, nonostante ci siano aspetti da gestire manualmente, come la creazione del messaggio, il suo utilizzo è tutto sommato semplice e di facile intuizione. Fortunatamente dalla versione 3.0 di Silverlight sarà molto più semplice realizzare servizi di questo genere, perché sarà presente un supporto completo da parte di Visual Studio e si potranno ricevere più azioni. Questa prima versione resta però valida, perché molti aspetti, soprattutto server, rimarranno invariati e si potrà facilmente migrare il codice.

Attenzione: Questo articolo contiene un allegato

Sullo stesso argomento

Commenti

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Segnala su: