Windows Communications Foundation

WCF Duplex Polling

Posted in Windows Communications Foundation on februari 16th, 2009 by erik – 1 Comment

Ett alternativ för kommunikation mellan server och klient till mitt förra inlägg är att använda sig av en WCF-tjänst som Silverlight-klienten pratar med. I Windows Azure är det möjligt att ha en WCF-tjänst i en webroll, vilket alltså skulle innebära att Silverlightklienterna i en webroll skulle tala med schackservern i en annan webroll. En WCF-tjänst kan förstås också finnas som ett konsolprogram eller på en vanlig webbserver.

Med Silverlight 2 lanserades metoden Duplex polling, som innebär att man kan skapa en anslutning mellan en Silverlight-applikation (klienten) och en WCF-duplextjänst (som vi kan kalla servern). Bakom kulisserna ligger Silverlight och “pollar”, alltså frågar servern om den har något nytt meddelande att hämta, hela tiden. Man kan själv bestämma hur ofta man vill att pollningen ska ske. Det här är en utmärkt metod för att hålla klienten uppdaterad på vad som händer på servern - men är inte optimalt om man behöver en realtidsanslutning.

Den stora fördelen med Duplex polling i jämförelse med att använda sockets (som ju är den gamla traditionella anslutningen man kan ha mellan en klient och en server) är att kommunikationen sker över port 80 - samma port som webbläsaren använder när man surfar. Därmed blockerar inte eventuella brandväggar trafiken till datorn. Använder du sockets kan användaren vara tvungen att öppna portar i sin brandvägg - och det är ju inte direkt önskvärt när det är en tjänst som man vill nå ut till många med.

Här finns MSDN-guiden till hur man upprättar en Duplex-polling kommunikation mellan WCF och Silverlight: http://msdn.microsoft.com/en-us/library/cc645026(VS.95).aspx
Dan Wahlin har också skrivit om hur du kan gå till väga med ett färdigt exempel att ladda ner: http://weblogs.asp.net/dwahlin/archive/2008/06/16/pushing-data-to-a-silverlight-client-with-wcf-duplex-service-part-i.aspx

 

Nackdelen med Duplex polling då? Jo, som jag nämnde är man inte garanterad en på millisekunden uppdaterad anslutning. Men det behöver de flesta inte ha (frågan är om jag behöver det eller inte? Det måste undersökas).

Duplex polling är inte heller direkt avsedd för att ha en anslutning mellan 1 server och många anslutningar. När jag har undersökt och även själv skapat en prototyp till en chattapplikation blir det problem så fort som en användare i chatten stänger ner webbläsaren, utan att först avsluta anslutningen till servern. Det som händer är att servern loopar igenom listan med klienter för att skicka meddelanden, och när den kommer till en klient som bara har försvunnit så märker den inte av det och letar tills anslutningen “timar out”. Att Duplex polling-tjänsten inte hanterar avbrutna anslutningar ordentligt blir potentiellt problematiskt när man har många användare anslutna och ett gäng stänger ner sina klienter samtidigt.

Jag har undersökt saken och det verkar inte finnas något som hanterar detta på ett bra sätt:
http://silverlight.net/forums/t/39205.aspx och http://silverlight.net/forums/t/17502.aspx

Min fundering nu är att bygga kommunikationslagret så pass modulärt så att jag kan byta ut det mellan Duplex polling och sockets, beroende på vad som fungerar bäst.