June 10, 2008
Creating a Silverlight 2 Client Access Policy Socket ServerDan Wahlin
Built-in support for sockets
Dan Wahlin (Microsoft Most Valuable Professional for ASP.NET and XML Web Services) is a .NET development instructor and architecture consultant at Interface Technical Training. Dan founded the XML for ASP.NET Developers site, which focuses on using ASP.NET, XML, Silverlight, AJAX, and Web Services on .NET and runs smartwebcontrols.com. He's also on the INETA Speaker's Bureau and speaks at several conferences. Dan has co-authored/authored several different books on .NET, including ASP.NET 2.0 MVP Hacks, Professional ASP.NET AJAX, XML for ASP.NET Developers and is currently working on a new book on Silverlight 2. Dan blogs at http://weblogs.asp.net/dwahlin.
Silverlight 2 provides built-in support for sockets which lets servers push data to Silverlight clients. Using this feature, clients can avoid polling servers on a timed basis to ensure that clients are kept up-to-date. If you're new to the socket features built-into Silverlight 2 you'll want to read my previous articles to get additional details about how data can be pushed from a server to a client:
Silverlight 2 Beta 2 (and beyond) checks for a client access policy before accessing sockets located on host domain or cross-domain servers. Listing One is an example of a client access policy for sockets.
<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*" />
</allow-from>
<grant-to>
<socket-resource port="4530" protocol="tcp" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Listing One
This XML code lets Silverlight access a TCP socket on port 4530. A range of ports can be specified in the port attribute if needed (ex: 4530-4532). Before Silverlight tries to call a server with a socket, it makes a call to the target server on port 943 to check the client access policy and see if the server allows socket connections. This helps minimize various types of hacker attacks. If a client access policy is available on the server and the policy allows access to the port the client is trying to call, processing of the socket code continues and Silverlight tries to connect. If not, the client will be unable to connect due to access being denied by Silverlight.
Listing Two is an example of creating a client access policy socket server that Silverlight can connect to on port 943: using System; using System.Collections.Generic; using System.Text; using System.Net; using System.Net.Sockets; using System.IO; using System.Threading; using System.Reflection; using System.Configuration;
Listing Two
Looking through the code you'll see that it uses the TcpListener class to listen for incoming client connections. Once a client connects the code checks the request for the following value:
<policy-file-request/>
Silverlight automatically sends this text to the policy file socket once it connects. If the request contains the proper value the code writes the contents of the client access policy back to the client stream (see the OnReceiveComplete() method). Once the policy file is received, Silverlight parses it, checks that it allows access to the desired port, and then accepts or rejects the socket call that the application is trying to make.
Figure 1 is an example of the Silverlight GameStream socket application I created to demonstrate the fundamentals of using sockets. You can download the complete application here.
[Click image to view at full size]
Figure 1:A Silverlight 2 interface that has data pushed to it from a socket server.
|
|
||||||||||||||||||||||||||||
|
|
|
|