XAML Playground
about XAML and other Amenities

Improve PollingDuplex reliability with Silverlight 3.0

2009-04-07T23:43:23+01:00 by Andrea Boschin

The need to consume a continuous flow of data from a RIA application has two tipical solution. The first one involve the use of a Socket channel and probably is the most realiable when there is full acces to the ports  exposed by a server to the network. But this is rarely an available solution. Firewall, proxies and other kind of network apparates often restrict the access to a very tiny set of ports, possibly only to the http port 80. In this case the last solution available is to continuous poll the server and pulling data at every timeout.

timetableThis tecnique is slightly inefficient and prone to overload the server. If the need is to have very fast updates you have to rely on very short timeout but this may cause the server to fail under a great number of clients. On the other side having a long timeout may lost precision on the updates and give bad informations to users.

Silverlight 2.0 introduced a new mode to consume WCF services that allow to have the better of the server polling, using the only available http port, without short timeouts. With long timeouts we may also have updates very quickly thanks to a smart polling tecnique. Polling a server usually cause the client to be connected to the server only for few milliseconds and between connections there is a long disconnected period (the timeout). With Silverlight 2.0 PollingDuplex, channels can be connected during the whole timeout period and disconnect only for the short time needed to refresh the connection or notify the client of available updates. To do this "magic" the PollingDuplex simply open a connection to the server and wait for this connection to expire for a given period of time. If something happen on the server during this waiting the connection will be closed by the server itself and the client receive the notification with the related data.

Since its implementation many months ago this tecnique has been covered by many articles on the Internet so we do not need to add some other words to them. Here we need instead to analyze the changes that Silverlight 3.0 have introduced in this implementation that grant the developer a more reliable and simple usage of the PollingDuplex channels. To explore this new model I introduce a simple but effective application that monitors bus traffic.

Setup PollingDuplexHttpBinding

With Silverlight 2.0 setting up a duplex channel was a task hard and prone to errors. Due to the missing of an auto generated proxy the creation of a duplex connection and the control of its lifetime involve the direct usage of WCF channels and the management of at least a thread to monitor the polling channel. A detailed article explaining this tecnique may be found .

The main activity for the Silverlight team on this feature was to simplify the task of establishing the connection. With Silverlight 3.0 Visual Studio now support the generation of proxy class directly from the IDE in a similar way what we do with normal WCF services.

After the creation of the proxy - where it is possible to set properties like the type to be used for collections and dictionaries - the IDE generates a client class that can be simply used to establish the connection and receive updates. Here is a snippet of code, from the downloadable source, that show how to complete this task:

   1: /// <summary>
   2: /// Starts this instance.
   3: /// </summary>
   4: public static void Start()
   5: {
   6:     CustomBinding binding = new CustomBinding(
   7:         new PollingDuplexBindingElement(),
   8:         new BinaryMessageEncodingBindingElement(),
   9:         new HttpTransportBindingElement());
  10:  
  11:     TimeServiceClient client = new TimeServiceClient(binding, GetEndPoint());
  12:     
  13:     client.UpdateReceived += new EventHandler<UpdateReceivedEventArgs>(client_UpdateReceived);
  14:     client.RegisterAsync();
  15: }

In this few lines of code the TimeServiceClient is created. This client has to be setup with a binding compatible with the binding exposed by the server. In this case we need a custom binding using the new binary XML through the BinaryMessageEncodingBindingElement. The other element used establish a PollingDuplex channel over an http transport.

The other lines of code attach an Update event (exposed by the CallbackContract interface) and then calls the Register method (exposed by the ServiceContract) to start the polling. When this method completes - and we have an event available to check about his completion - the channel is up and running. Every time an update is available the UpdateReceived event will be raised and we may update the interface according to this data.

On the client the work is done. There is no need to have threads and all the received updates are always marshaled to the UI thread context so it is possible to update directly the User Interface.

In this sample we will simulate a timetable that show incoming races on a bus stop. When a bus is arriving to the stop the server will update the connected clients that will shows the times on the Silverlight scene. In this scenario we need to have very quicly updates and to minimize the traffic and the server work.

Creating a WCF Polling Server

The server side of the polling channel is slightly more complicated. This is not due to complexity of the PollingDuplex channel, but due to the needs to maintain trace of the registered clients and to notify them every time an update is available.

A polling duplex channel is made of two contracts instead of the usual one of normal WCF services. The first contract represent the normal ServiceContract that expose the ServiceOperations available to be called. On the other way we need to have a CallbackContract that say how a server can call on a client when an update is available and needs to notify it.

When a client connect to the service, using the Register method, the service itself will ask the OperationContext about the CallbackContract available over the client. An instance of the contract, returned by the GetCallbackChannel<T>() method will be retained by the service and used whenever it need to notify clients. Mantaining this instances needs to manage a shared collection of items and syncronize access to the elements using a lock statement. This is required because when a service instance has been created it is shared by all the calls that the service handles. So in a multi threaded environment like the context of a running webserver we have to keep in mind that the concurrency on the client callbacks contracts can affect the performances of out system.

In the sample attached to this article this responsability is of the TimeRunner class that handles the clinet collection and manage locks:

   1: /// <summary>
   2: /// Registers the specified client.
   3: /// </summary>
   4: /// <param name="client">The client.</param>
   5: public static void Register(ITimeServiceClient client)
   6: {
   7:     lock (lockObj)
   8:     {
   9:         TimeClient timeClient = new TimeClient(client);
  10:         timeClient.Fault += new EventHandler(timeClient_Fault);
  11:         TimeRunner.Clients.Add(timeClient);
  12:  
  13:         // ... omissis ...
  14:     }
  15: }

Another responsibility we have on the server side is the management of the client Fault states. A fault is the condition we may encounter when trying to send and update to a callback we get an exception because the client has been closed. There is no way to be notified about client disconnection so the only way to get rid of this problem is catching exceptions during an update. For each client connected to the service it will create an instance of a TimeClient class. This class checks the fault states when a client is updating and raise an event that signal to the TimeRunner the needs of remove the TimeClient instance from the collection:

   1: /// <summary>
   2: /// Handles the Fault event of the timeClient control.
   3: /// </summary>
   4: /// <param name="sender">The source of the event.</param>
   5: /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param>
   6: private static void timeClient_Fault(object sender, EventArgs e)
   7: {
   8:     lock (lockObj)
   9:     {
  10:         TimeClient timeClient = (TimeClient)sender;
  11:         TimeRunner.Clients.Remove(timeClient);
  12:         timeClient.Dispose();
  13:     }
  14: }

Let doing something...

Now that the service communication layer has been prepared to handle multiple incoming requests and updates we need to proceed start doing something in the service. While a normal WCF service simply handle calls from the web to do its work syncronous with the client, a Duplex service has to act as a worker thread that get notifications about the monitored resource and then contact the clients to send updates. The worker thread can wait for a database table to be updated, or can wait for other incoming event. In my sample I use a FileSystemWatcher to monitor changes to an xml file. The timetable.xml file contains sample data about races passing in a bus stop. I imagined that a windows service is collecting informations about the bus running ina town and when it have updates simply write to a xml file. This writing is catched by the FileSystemWatcher and notify the WCF duplex service thread. The notification received by the service cause the timetable to be loaded and a diffgram is send to the connected clients.

   1: /// <summary>
   2: /// Handles the Changed event of the Watcher control.
   3: /// </summary>
   4: /// <param name="sender">The source of the event.</param>
   5: /// <param name="e">The <see cref="System.IO.FileSystemEventArgs"/> instance containing the event data.</param>
   6: private static void Watcher_Changed(object sender, FileSystemEventArgs e)
   7: {
   8:     RacesTable table = LoadRaces();
   9:  
  10:     RaceUpdate update = new RaceUpdate
  11:     {
  12:         AddedOrModified = (from upd in table.Races
  13:                            where !TimeRunner.CurrentTable.Races.Contains(upd)
  14:                            select upd).ToArray(),
  15:         Deleted = (from old in TimeRunner.CurrentTable.Races
  16:                    where !table.Races.Select(rc => rc.UniqueID).Contains(old.UniqueID)
  17:                    select old).ToArray()
  18:     };
  19:  
  20:     lock (lockObj)
  21:     {
  22:         for(int i=0; i<TimeRunner.Clients.Count; i++)
  23:         {
  24:             TimeClient client = TimeRunner.Clients[i];
  25:             if (!client.IsSending) client.Send(update);
  26:         }
  27:     }
  28:  
  29:     TimeRunner.CurrentTable = table;
  30: }

The diffgram is calculated using an image of the timetable in memory that contains the latest version of the file. The new file and the old image is compared using linq and the diffgram is created with Added, Modified and Deleted items. The client that receive this update simply apply this changes tho his own copy of the timetable. The only exception to this flow happen when a client connect . In this case it get the complete content of the timetable from the memory of the service.

Hosting service and serving policies

A duplex service may be hosted by Internet Information Service, by a windows service or by a simple console application. In this example I choose to use a console application to maintain the source code simple. While using the IIS as host allow to serve clientaccesspolicy.xml files in a simple way, using a windows process needs to implements some tricks to serve this file as we did if we have a webserver. To do this I've implemented an endpoint using the webHttpBinding and return the xml file when it is requested. For more detail on this tecnique please read this .

Now that the sample has been described you may run it by yourself. Firts of all you need to run the service application and then starts the web application containing the Silverlight xap.

Download: Elite.Silverlight3.Polling.zip (1,4 MB)
Categories:   Networking
Actions:   E-mail | del.icio.us | Permalink | Comments (17) | Comment RSSRSS comment feed

A proxy class to tunnel Socket channels

2009-04-01T23:00:00+01:00 by Andrea Boschin

One of the requests I found, following the Silverlight forums, is the capability to connect a Socket to an arbitrary port out of the restricted range where Silverlight is allowed to work. Since the release 2.0, Silverlight is allowed to connect to the network using a Socket but has a limitation that forbid the access to ports out of the range from 4502 to 4534. Another requirements for the sockets to work is that the same service must expose a clientaccesspolicy.xml file on a well known port 943 stating the ports opened by the service.

This complicated context let the use of the Sockets difficult and limitated to custom services. The limit of 32 ports opened is fine if someone has to create a custom service giving realtime updates, but is frustrating if the need is to access a well know network service like DNS, Telnet and other. We have to know that some network protocols are impossible to be implemented with Silverlight because of them nature. Thinking about FTP the duplex nature of this service, where server and client exchange their role (the client become server when receiving a file)  let this protocol impossible to be implemented in Silverlight where there is no way to listen to incoming connections. There is a number of other existing services, and often a number of existing custom services that rely on ports out of the 4502-4534 range and that we would like to consume without changing the code because often they are already published to other systems.

In this article I will explain a simple project I've implemented to let some services to be "tunneled" moving their original port to another port in the range allowed to Silverlight. This service that is freely downloadable at the end of the post, also implements a channel on the port 943 to allow Silverlight to get the client access policies before to connect to the tunneled ports.

The system Architecture

Before showing some snippets of code I will try to explain how my solution works. I will go through the architecture showing the components and the reason of my choice. The first concept you may know about implementing Sockets is that when you are listening on a port you are waiting for accepting clients and when a client connect you need to start a thread that take the accepted client and manage it separately from the main listening socket. This behavioh allow you to manage multiple incoming clients giving each connection in charge to a separate thread and leaving the port free to return a the listening task. Another requirement we have developing the solution for Silverlight is to have two servers listening, one for the policy distribution and the other on the proxy service that forward traffic to the required port.

To solve this problem I've created a base class ThreadedObject that implements the base behavior of every subsystem. From this class I've inherited three types that manage the different parts of the problem.

classes

The ThreadedObject class is in charge of managing the lifetime of the thread. It is a IDisposable class so it is created with an using construct and this cause the closing of the thread when the class goes out of scope. The trick is the usage of a ManualResetEvent exposed to the subclasses. When this event will be set the thread has to exit gracefully.

The SocketProxy class

This class have in charge the task to listen for incoming connections on both the policy port 943 and the proxy channel that we will expose on the port 4530. I've created this class thinking about a developer that needs to embed a listening proxy in a Windows service. It is a simple class that request a few parameters in input and when started run a thread that listen. As you may know the parameters tells the host and the ports where to listen and forward connections. In my solution this parameters are read from the app.config file. The constructor wants also the path of a policy file. Here is the main thread procedure of the class:

   1: /// <summary>
   2: /// Listen the thread.
   3: /// </summary>
   4: /// <param name="state">The state.</param>
   5: protected override void ThreadProc()
   6: {
   7:     IPHostEntry hostEntry = Dns.GetHostEntry(this.ListenHost);
   8:     IPAddress ipAddress = hostEntry.AddressList.Where(entry => entry.AddressFamily == AddressFamily.InterNetwork).FirstOrDefault();
   9:  
  10:     if (ipAddress != null)
  11:     {
  12:         this.PolicyListener = new TcpListener(ipAddress, 943);
  13:         this.PolicyListener.Start();
  14:         this.ProxyListener = new TcpListener(ipAddress, this.ListenPort);
  15:         this.ProxyListener.Start();
  16:  
  17:         while (WaitHandle.WaitTimeout == WaitHandle.WaitAny(this.ExitHandles, 10))
  18:         {
  19:             if (this.PolicyListener.Pending())
  20:             {
  21:                 PolicyClient policyClient =
  22:                     new PolicyClient(this.PolicyListener.AcceptTcpClient(), this.PolicyFile);
  23:                 policyClient.Start();
  24:  
  25:             }
  26:             else if (this.ProxyListener.Pending())
  27:             {
  28:                 ProxyClient proxyClient = 
  29:                     new ProxyClient(this.ProxyListener.AcceptTcpClient(), this.TargetHost, this.TargetPort);
  30:                 proxyClient.Start();
  31:             }
  32:         }
  33:     }
  34:     else
  35:         throw new ApplicationException(Resources.CannotResolveAddress);
  36: }

The class starts two instances of TcpListener and then poll the Pending() method to check when there is waiting clients to accept. When a client is ready it starts an instance of the managing type.

The PolicyClient

This class implements a manager for the clients requesting the policies. It will be started by the SocketProxy class when a client ask for a connection. The class operate in two steps: first of all it wait for the client to send the policy request string then it sends the policy file and finally close the connection:

   1: /// <summary>
   2: /// Threads the proc.
   3: /// </summary>
   4: protected override void ThreadProc()
   5: {
   6:     try
   7:     {
   8:         while (WaitHandle.WaitTimeout == WaitHandle.WaitAny(this.ExitHandles, 10) &&
   9:             this.Client.Available == 0) ;
  10:  
  11:         ReadAndSend();
  12:     }
  13:     finally
  14:     {
  15:         this.Client.Close();
  16:     }
  17: }
  18:  
  19: /// <summary>
  20: /// Validates the and send.
  21: /// </summary>
  22: /// <returns></returns>
  23: private void ReadAndSend()
  24: {
  25:     NetworkStream stream = this.Client.GetStream();
  26:  
  27:     byte[] data = new byte[PolicyRequestString.Length];
  28:     stream.Read(data, 0, data.Length);
  29:  
  30:     string readString = Encoding.UTF8.GetString(data);
  31:  
  32:     if (readString == PolicyRequestString)
  33:     {
  34:         stream.Write(this.PolicyFile, 0, this.PolicyFile.Length);
  35:         stream.Flush();
  36:     }
  37: }

The class request in the constructor a byte array of the policy file to send. This buffer is loaded by the SocketProxy class and then decoded to a byte array and passed to all the instances.

The ProxyClient

This is the most critical class that have in charge the clients when tunneling the traffic in both the directions. It will have two clients; the silverlight part and the tunneled service part. It simply wait for traffic from each client and forward it to the other. The operation of tunneling the data is the critical part. I read the data from a channel in 1024 bytes chunks and write the same bytes on the other client. I think this part has to be tested on various services and tuned finding the best strategy. The current implementation may fail when both parts of the channel is data intensive because reading data from a channel stops reading data from the other.

   1: /// <summary>
   2: /// Threads the proc.
   3: /// </summary>
   4: protected override void ThreadProc()
   5: {
   6:     try
   7:     {
   8:         while (WaitHandle.WaitTimeout == WaitHandle.WaitAny(this.ExitHandles, 10) &&
   9:             this.Client.Available == 0) ;
  10:  
  11:         ReadAndSend();
  12:     }
  13:     finally
  14:     {
  15:         this.Client.Close();
  16:     }
  17: }
  18:  
  19: /// <summary>
  20: /// Validates the and send.
  21: /// </summary>
  22: /// <returns></returns>
  23: private void ReadAndSend()
  24: {
  25:     NetworkStream stream = this.Client.GetStream();
  26:  
  27:     byte[] data = new byte[PolicyRequestString.Length];
  28:     stream.Read(data, 0, data.Length);
  29:  
  30:     string readString = Encoding.UTF8.GetString(data);
  31:  
  32:     if (readString == PolicyRequestString)
  33:     {
  34:         stream.Write(this.PolicyFile, 0, this.PolicyFile.Length);
  35:         stream.Flush();
  36:     }
  37: }

Testing the application

To test the class I've selected a service from the canonical ports exposed by a system.  Finally I've selected the daytime port 13. It is a service that on Windows has to be installed under the Simple TCP services and then started by the Services applet. The choice of this simple and slightly unuseful ports is only to give a very simple example that show how to expose a port that is really out of the Silverlight range. My simple application has a button and a TextBlock. When the Button is clicked a Socket connection will be made to appthe daytime service and the returned system time will be displayed in the TextBlock.

The server part is configured to tunnel connection incoming on port 4530 to the system dtaytime port and to serve a policy file from the file system.

I'm thinking to write a more powerful sample on this code. Opening ports to the silverlight applications may open a wide range of solutions limited only by your creativity and probably by your it manager. When exposing a port on the internet you have to concern about security issues. Every opened port to the network is a potential security disclosure but the security must be implemented in the protocol you are exposing. Also you have to know that exposing a well-know port may give an opportunity to use a well know bug to enter your system.

Download: Elite.Silverlight.SocketProxy.zip (1,1 MB)