Olika roller
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:
- Jag skickar mitt drag: 1.e4 till min motståndare i min webbläsare.
- Webbrollen tar mitt drag och lagrar det i “cloud storage” (se bild norpad från Johan Lindfors nedan)
- 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
- 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.
[...] 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 [...]