Schack i molnet

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.

Jag insåg ganska snart när jag började fundera på detta projekt att det är själva kommunikationen mellan servern och klienten  som kommer att bli den svåra nöten. Servern har hand om alla partier och länkar samman användarna medan klienten är den programvara som varje användare kör på sin dator. I detta fall är klienten en Silverlight-applikation som bäddas in i en hemsida, och alltså körs direkt i webbläsaren.

På serversidan finns många olika vägar att gå, och den initiala vägen var Windows Azure. Efter en tids grävande på nätet i forum och bloggar så visar det sig att Azure inte är direkt anpassat för att vara back-end för en applikation som kräver närapå direktkontakt mellan klienterna.

Sättet som Azure jobbar är genom att ha två olika “roller” som man kan skapa. En web-role, som kan vara en hemsida t ex (alltså fungera som en Silverlight-klient i mitt fall), samt en worker-role som fungerar som en tjänst (eng: service, och skulle fungera som själva schackservern som klienterna ansluter till).

Problemet är att webbrollen och workerrollen inte pratar direkt med varandra, utan att man måste använda sig av ett lagringsmedium som mellan-länk.

Säg att jag på min klient skickar ett schack drag till min motståndare:

1. Jag skickar mitt drag: 1.e4 till min motståndare i min webbläsare.
2. Webbrollen tar mitt drag och lagrar det i “cloud storage” (se bild norpad från Johan Lindfors nedan)
3. Workerrollen som ständigt ligger och tittar i cloud storage ser att det har kommit ett nytt drag. Han(?) plockar upp draget, ser om det är giltigt och lagrar det tillbaka i en annan cloud storage
4. Min motståndare som sitter i sin webbläsare är ju också ansluten med en “egen” webbroll som ligger och tittar i cloud storage efter nya drag, och vips kommer ett drag från workerrollen som den plockar upp och visar på skärmen för motståndaren: 1.e4

Azures arkitektur

Som synes är det inte en optimal lösning då man som schackspelare vill ha en blixtsnabb kommunikation med sin motståndare. Möjligen är det en omväg att försöka bygga det här för Azure, men jag har inte riktigt gett upp hoppet än. Men det är värt att titta på alternativ.

Azure, WCF Duplex Polling eller gamla hederliga Sockets? Det är frågan.

On another note: Jag har nu klart ett anpassat bibliotek för att kontrollera ett schackdrags giltighet som kan köras både i klienten och på servern, samt börjat med ett silverlight-bräde som börjar bete sig som jag vill.