Many applications have
the need
to stay in-sync with data provided by a service. Although web applications typically rely on standard polling techniques
to check if data has changed, Silverlight provides several interesting options for keeping an application in-sync that rely on server “push” technologies. A few years
back I wrote several blog posts covering different “push” technologies available in Silverlight that rely on sockets or HTTP Polling Duplex. We recently had a project that looked like it could benefit from pushing data from a server
to one or more clients so I thought I’d revisit
the subject and provide some updates
to the original code posted. If you’ve worked with AJAX before in Web applications then you know that until browsers fully support web sockets or other duplex (bi-directional communication) technologies that it’s difficult
to keep applications in-sync with a server without relying on polling.
The problem with polling is that you have
to check for changes on
the server on a timed-basis which can often be wasteful and take up unnecessary resources. With server “push” technologies, data can be pushed from
the server
to the client as it changes. Once
the data is received,
the client can update
the user interface as appropriate. Using “push” technologies allows
the client
to listen for changes from
the data but stay 100% focused on client activities as opposed
to worrying about polling and asking
the server if anything has changed. Silverlight provides several options for pushing data from a server
to a client including sockets, TCP bindings and HTTP Polling Duplex. Each has its own strengths and weaknesses as far as performance and setup work with HTTP Polling Duplex arguably being
the easiest
to setup and get going. In this article I’ll demonstrate how HTTP Polling Duplex can be used in Silverlight 4 applications
to push data and show how you can create a WCF server that provides an HTTP Polling Duplex binding that a Silverlight client can consume. What is HTTP Polling Duplex? Technologies that allow data
to be pushed from a server
to a client rely on duplex functionality. Duplex (or bi-directional) communication allows data
to be passed in both directions. A client can call a service and
the server can call
the client. HTTP Polling Duplex (as its name implies) allows a server
to communicate with a client without forcing
the client
to constantly poll
the server. It has
the benefit of being able
to run on port 80 making setup a breeze compared
to the other options which require specific ports
to be used and cross-domain policy files
to be exposed on port 943 (as with sockets and TCP bindings). Having said that, if you’re looking for
the best speed possible then sockets and TCP bindings are
the way
to go. But, they’re not
the only game in town when it comes
to duplex communication.
The first time I heard about HTTP Polling Duplex (initially available in Silverlight 2) I wasn’t exactly sure how it was any better than standard polling used in AJAX applications. I read
the Silverlight SDK, looked at various resources and generally found
the following definition unhelpful as far as understanding
the actual benefits that HTTP Polling Duplex provided: "The Silverlight client periodically polls
the service on
the network layer, and checks for any new messages that
the service wants
to send on
the callback channel.
The service queues all messages sent on
the client callback channel and delivers them
to the client when
the client polls
the service." Although
the previous definition explained
the overall process, it sounded as if standard polling was used. Fortunately, Microsoft’s Scott Guthrie provided me with a more clear definition several years
back that explains
the benefits provided by HTTP Polling Duplex quite well (used with his permission): "The [HTTP Polling Duplex] duplex support does use polling in
the background
to implement notifications – although
the way it does it is different than manual polling. It initiates a network request, and then
the request is effectively “put
to sleep” waiting for
the server
to respond (it doesn’t come
back immediately).
The server then keeps
the connection open but not active until it has something
to send
back (or
the connection times out after 90 seconds – at which point
the duplex client will connect again and wait). This way you are avoiding hitting
the server repeatedly – but still get an immediate response when there is data
to send." After hearing Scott’s definition
the light bulb went on and it all made sense. A client makes a request
to a server
to check for changes, but instead of
the request returning immediately, it parks itself on
the server and waits for data. It’s kind of like waiting
to pick up a pizza at
the store. Instead of calling
the store over and over
to check
the status, you sit in
the store and wait until
the pizza (the request data) is ready. Once it’s ready you take it
back home (to
the client). This technique provides a lot of efficiency gains over standard polling techniques even though it does use some polling of its own as a request is initially made from a client
to a server. So how do you implement HTTP Polling Duplex in your Silverlight applications? Let’s take a look at
the process by starting with
the server. Creating an HTTP Polling Duplex WCF Service Creating a WCF service that exposes an HTTP Polling Duplex binding is straightforward as far as coding goes. Add some one way operations into an interface, create a client callback interface and you’re ready
to go.
The most challenging part comes into play when configuring
the service
to properly support
the necessary binding and that’s more of a cut and paste operation once you know
the configuration code
to use.
To create an HTTP Polling Duplex service you’ll need
to expose server-side and client-side interfaces and reference
the System.ServiceModel.PollingDuplex assembly (located at C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Server on my machine) in
the server project. For
the demo application I upgraded a basketball simulation service
to support
the latest polling duplex assemblies.
The service simulates a simple basketball game using a Game class and pushes information about
the game such as score, fouls, shots and more
to the client as
the game changes over time. Before jumping too far into
the game push service, it’s important
to discuss two interfaces used by
the service
to communicate in a bi-directional manner.
The first is called IGameStreamService and defines
the methods/operations that
the client can call on
the server (see Listing 1).
The second is IGameStreamClient which defines
the callback methods that a server can use
to communicate with a client (see Listing 2). [ServiceContract(Namespace = "Silverlight", CallbackContract = typeof(IGameStreamClient))]
public interface IGameStreamService
{
[OperationContract(IsOneWay = true)]
void GetTeamData();
}
Listing 1.
The IGameStreamService interface defines server operations that can be called on
the server.
[ServiceContract]
public interface IGameStreamClient
{
[OperationContract(IsOneWay = true)]
void ReceiveTeamData(List<Team> teamData);
[OperationContract(IsOneWay = true, AsyncPattern=true)]
IAsyncResult BeginReceiveGameData(GameData gameData, AsyncCallback callback, object state);
void EndReceiveGameData(IAsyncResult result);
}
Listing 2.
The IGameStreamClient interfaces defines client operations that a server can call.
The IGameStreamService interface is decorated with
the standard ServiceContract attribute but also contains a value for
the CallbackContract property. This property is used
to define
the interface that
the client will expose (IGameStreamClient in this example) and use
to receive data pushed from
the service. Notice that each OperationContract attribute in both interfaces sets
the IsOneWay property
to true. This means that
the operation can be called and passed data as appropriate, however, no data will be passed
back. Instead, data will be pushed
back to the client as it’s available. Looking through
the IGameStreamService interface you can see that
the client can request team data whereas
the IGameStreamClient interface allows team and game data
to be received by
the client.
One interesting point about
the IGameStreamClient interface is
the inclusion of
the AsyncPattern property on
the BeginReceiveGameData operation. I initially created this operation as a standard one way operation and it worked most of
the time. However, as I disconnected clients and reconnected new ones game data wasn’t being passed properly. After researching
the problem more I realized that because
the service could take up
to 7 seconds
to return game data, things were getting hung up. By setting
the AsyncPattern property
to true on
the BeginReceivedGameData operation and providing a corresponding EndReceiveGameData operation I was able
to get around this problem and get everything running properly. I’ll provide more details on
the implementation of these two methods later in this post.
Once
the interfaces were created I moved on
to the game service class.
The first order of business was
to create a class that implemented
the IGameStreamService interface. Since
the service can be used by multiple clients wanting game data I added
the ServiceBehavior attribute
to the class definition so that I could set its InstanceContextMode
to InstanceContextMode.Single (in effect creating a Singleton service object). Listing 3 shows
the game service class as well as its fields and constructor.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)]
public class GameStreamService : IGameStreamService
{
object _Key = new object();
Game _Game = null;
Timer _Timer = null;
Random _Random = null;
Dictionary<string, IGameStreamClient> _ClientCallbacks = new Dictionary<string, IGameStreamClient>();
static AsyncCallback _ReceiveGameDataCompleted = new AsyncCallback(ReceiveGameDataCompleted);
public GameStreamService()
{
_Game = new Game();
_Timer = new Timer { Enabled = false, Interval = 2000, AutoReset = true }; _Timer.Elapsed += new ElapsedEventHandler(_Timer_Elapsed);
_Timer.Start();
_Random = new Random();
}}
Listing 3.
The GameStreamService implements
the IGameStreamService interface which defines a callback contract that allows
the service class
to push data
back to the client.
By implementing
the IGameStreamService interface, GameStreamService must supply a GetTeamData() method which is responsible for supplying information about
the teams that are playing as well as individual players. GetTeamData() also acts as a client subscription method that tracks clients wanting
to receive game data. Listing 4 shows
the GetTeamData() method.
public void GetTeamData()
{
//Get client callback channel
var context = OperationContext.Current;
var sessionID = context.SessionId;
var currClient = context.GetCallbackChannel<IGameStreamClient>();
context.Channel.Faulted += Disconnect;
context.Channel.Closed += Disconnect;
IGameStreamClient client;
if (!_ClientCallbacks.TryGetValue(sessionID, out client))
{
lock (_Key)
{
_ClientCallbacks[sessionID] = currClient;
}
}
currClient.ReceiveTeamData(_Game.GetTeamData());
//Start timer which when fired sends updated score information
to client
if (!_Timer.Enabled)
{
_Timer.Enabled = true;
}
}
Listing 4.
The GetTeamData() method subscribes a given client
to the game service and returns.
The key
the line of code in
the GetTeamData() method is
the call
to GetCallbackChannel<IGameStreamClient>(). This method is responsible for accessing
the calling client’s callback channel.
The callback channel is defined by
the IGameStreamClient interface shown earlier in Listing 2 and used by
the server
to communicate with
the client. Before passing team data
back to the client, GetTeamData() grabs
the client’s session ID and checks if it already exists in
the _ClientCallbacks dictionary object used
to track clients wanting callbacks from
the server. If
the client doesn’t exist it adds it into
the collection. It then pushes team data from
the Game class
back to the client by calling ReceiveTeamData(). Since
the service simulates a basketball game, a timer is then started if it’s not already enabled which is then used
to randomly send data
to the client.
When
the timer fires, game data is pushed down
to the client. Listing 5 shows
the _Timer_Elapsed() method that is called when
the timer fires as well as
the SendGameData() method used
to send data
to the client.
void _Timer_Elapsed(object sender, ElapsedEventArgs e)
{
int interval = _Random.Next(3000, 7000);
lock (_Key)
{
_Timer.Interval = interval;
_Timer.Enabled = false;
}
SendGameData(_Game.GetGameData());
}
private void SendGameData(GameData gameData)
{
var cbs = _ClientCallbacks.Where(cb => ((IContextChannel)cb.Value).State == CommunicationState.Opened);
for (int i = 0; i < cbs.Count(); i++)
{
var cb = cbs.ElementAt(i).Value;
try
{
cb.BeginReceiveGameData(gameData, _ReceiveGameDataCompleted, cb);
}
catch (TimeoutException texp)
{
//Log timeout error
}
catch (CommunicationException cexp)
{
//Log communication error
}
}
lock (_Key) _Timer.Enabled = true;
}
private static void ReceiveGameDataCompleted(IAsyncResult result)
{
try
{
((IGameStreamClient)(result.AsyncState)).EndReceiveGameData(result);
}
catch (CommunicationException)
{
// empty
}
catch (TimeoutException)
{
// empty
}
}
LIsting 5. _Timer_Elapsed is used
to simulate time in a basketball game.
When _Timer_Elapsed() fires
the SendGameData() method is called which iterates through
the clients wanting
to be notified of changes. As each client is identified, their respective BeginReceiveGameData() method is called which ultimately pushes game data down
to the client. Recall that this method was defined in
the client callback interface named IGameStreamClient shown earlier in Listing 2. Notice that BeginReceiveGameData() accepts _ReceiveGameDataCompleted as its second parameter (an AsyncCallback delegate defined in
the service class) and passes
the client callback as
the third parameter.
The initial version of
the sample application had a standard ReceiveGameData() method in
the client callback interface. However, sometimes
the client callbacks would work properly and sometimes they wouldn’t which was a little baffling at first glance. After some investigation I realized that I needed
to implement an asynchronous pattern for client callbacks
to work properly since 3 – 7 second delays are occurring as a result of
the timer. Once I added
the BeginReceiveGameData() and ReceiveGameDataCompleted() methods everything worked properly since each call was handled in an asynchronous manner.
The final task that had
to be completed
to get
the server working properly with HTTP Polling Duplex was adding configuration code into web.config. In
the interest of brevity I won’t post all of
the code here since
the sample application includes everything you need. However, Listing 6 shows
the key configuration code
to handle creating a custom binding named pollingDuplexBinding and associate it with
the service’s endpoint.
<bindings>
<customBinding>
<binding name="pollingDuplexBinding">
<binaryMessageEncoding />
<pollingDuplex maxPendingSessions="2147483647" maxPendingMessagesPerSession="2147483647" inactivityTimeout="02:00:00" serverPollTimeout="00:05:00"/>
<httpTransport />
</binding>
</customBinding>
</bindings>
<services>
<service name="GameService.GameStreamService" behaviorConfiguration="GameStreamServiceBehavior">
<endpoint address="" binding="customBinding" bindingConfiguration="pollingDuplexBinding" contract="GameService.IGameStreamService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
Listing 6. Configuring an HTTP Polling Duplex binding in web.config and associating an endpoint with it.
Calling
the Service and Receiving “Pushed” Data
Calling
the service and handling data that is pushed from
the server is a simple and straightforward process in Silverlight. Since
the service is configured with a MEX endpoint and exposes a WSDL file, you can right-click on
the Silverlight project and select
the standard Add Service Reference item. After
the web service proxy is created you may notice that
the ServiceReferences.ClientConfig file only contains an empty configuration element instead of
the normal configuration elements created when creating a standard WCF proxy. You can certainly update
the file if you want
to read from it at runtime but for
the sample application I fed
the service URI directly
to the service proxy as shown next:
var address = new EndpointAddress("http://localhost.:5661/GameStreamService.svc");
var binding = new PollingDuplexHttpBinding();
_Proxy = new GameStreamServiceClient(binding, address);
_Proxy.ReceiveTeamDataReceived += _Proxy_ReceiveTeamDataReceived;
_Proxy.ReceiveGameDataReceived += _Proxy_ReceiveGameDataReceived;
_Proxy.GetTeamDataAsync();
This code creates
the proxy and passes
the endpoint address and binding
to use
to its constructor. It then wires
the different receive events
to callback methods and calls GetTeamDataAsync(). Calling GetTeamDataAsync() causes
the server
to store
the client in
the server-side dictionary collection mentioned earlier so that it can receive data that is pushed. As
the server-side timer fires and game data is pushed
to the client,
the user interface is updated as shown in Listing 7. Listing 8 shows
the _Proxy_ReceiveGameDataReceived() method responsible for handling
the data and calling UpdateGameData()
to process it.
Listing 7.
The Silverlight interface. Game data is pushed from
the server
to the client using HTTP Polling Duplex.
void _Proxy_ReceiveGameDataReceived(object sender, ReceiveGameDataReceivedEventArgs e)
{
UpdateGameData(e.gameData);
}
private void UpdateGameData(GameData gameData)
{
//Update Score
this.tbTeam1Score.Text = gameData.Team1Score.ToString();
this.tbTeam2Score.Text = gameData.Team2Score.ToString();
//Update ball visibility
if (gameData.Action != ActionsEnum.Foul)
{
if (tbTeam1.Text == gameData.TeamOnOffense)
{
AnimateBall(this.BB1, this.BB2);
}
else //Team 2
{
AnimateBall(this.BB2, this.BB1);
}
}
if (this.lbActions.Items.Count > 9) this.lbActions.Items.Clear();
this.lbActions.Items.Add(gameData.LastAction);
if (this.lbActions.Visibility == Visibility.Collapsed) this.lbActions.Visibility = Visibility.Visible;
}
private void AnimateBall(Image onBall, Image offBall)
{
this.FadeIn.Stop();
Storyboard.SetTarget(this.FadeInAnimation, onBall);
Storyboard.SetTarget(this.FadeOutAnimation, offBall);
this.FadeIn.Begin();
}
Listing 8. As
the server pushes game data,
the client’s _Proxy_ReceiveGameDataReceived() method is called
to process
the data.
In a real-life application I’d go with a ViewModel class
to handle retrieving team data, setup data bindings and handle data that is pushed from
the server. However, for
the sample application I wanted
to focus on HTTP Polling Duplex and keep things as simple as possible.
Summary
Silverlight supports three options when duplex communication is required in an application including TCP bindins, sockets and HTTP Polling Duplex. In this post you’ve seen how HTTP Polling Duplex interfaces can be created and implemented on
the server as well as how they can be consumed by a Silverlight client. HTTP Polling Duplex provides a nice way
to “push” data from a server while still allowing
the data
to flow over port 80 or another port of your choice.
Sample Application Download
