On a recent project I worked on I had a need to create a client-server application. What I was after was real-time updating of the clients when data on the server changed. These sorts of applications crop up from time to time in one’s career, and they present a unique set of challenges. I figured I’d store the results of my work on my blog, and if it helps someone else then great.
I am not posting the actual application here because it relies on some machine-specific hardware devices, but what I did instead was to extract the core functionality out into a sample application that shows how the duplex service is constructed and how it is used. I created a simple service that contains a list of Movies. The clients have the ability to add a new Movie to the server, or delete an existing one. There’s no fancy business rules or elaborate domain objects because I’m mostly interested in documenting the duplex service usage.
You can download the application
here. It was written in C#, .Net 3.5. It utilizes
StructureMap for dependency injection (which I highly recommend) and I’ve included that library with the package. The executable files are included in the corresponding /bin directories so you don’t have to compile the application if you want to see it work.
Notes:
- The server is a console application. It will write to the console when a client subscribes or unsubscribes from the service, and it will print the count of the remaining subscribers.
- To see the real-time updating in action, open two clients. Add a new movie title to the list in one client and you’ll see the immediate update in both clients.
WCF Duplex Service Contract
A note about this service: You will notice I am passing .Net objects across the wire with this service. There are no data transfer objects and no requirements for interoperability. I have complete control over both sides of the wire; the client and server applications. And in general, when you are writing a client-server app that’s going to be the case. This is not a “web services” solution; there are plenty of those already.
There is a caveat to creating and using a WCF Duplex service: You have to keep the connection open if you want your client to respond to callbacks. With WCF, once a connection falls into a Faulted state it becomes useless, and there’s no going re-connecting. You have to re-create the connection from scratch.
Normally, when using a one-way service, you only create the connection for as long as it takes you to call the service. But here we want our client to actively listen to callbacks from the service (as opposed to polling the service, which puts the burden for updates on the client and can leave the client with stale data). To make that happen we have to utilize a keepalive call with a timer, so that we ping the service frequently enough to maintain the connection. WCF will timeout a connection after 10 minutes of inactivity due to the way the underlying timeout scheme is written, and I have yet to find a single configuration knob that will allow a connection to live longer than that in a reliable fashion. The keepalive, however, works and is rock solid.
My service implements two interfaces. One is for the plumbing associated with subscribing and unsubscribing to the service, and using a keepalive to maintain the connection to the service. The second interface is the one the client is really interested in, and has all the calls to deal with the data. You don’t have to separate these interfaces; I did because it shields the client from having to see those plumbing methods (they can still get to them if they cast want to it).
The plumbing interface looks like this:
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof (IMovieServiceCallback))]
public interface IDuplexService
{
[OperationContract]
bool KeepAlive();
[OperationContract]
void Subscribe();
[OperationContract]
void Unsubscribe();
}
The second service interface looks like this:
[ServiceContract(SessionMode = SessionMode.Required, CallbackContract = typeof(IMovieServiceCallback))]
public interface IMovieService : IDuplexService
{
[OperationContract]
IList<Movie> FindAll();
[OperationContract]
bool Exists(string title);
[OperationContract]
void Add(string title);
[OperationContract]
void Delete(Movie movie);
}
In both cases I’ve decorated the service interface with the [ServiceContract] attribute and specified the [CallbackContract], which looks like this:
public delegate void MoviesChangedEventHandler();
public interface IMovieServiceCallback
{
event MoviesChangedEventHandler OnMoviesChanged;
[OperationContract]
void MoviesChanged();
}
The only thing that’s left to do on the client side is setup the configuration file where we specify the WCF settings and then implement the interface. I’m not going to post the XML here (you can download the sample app to see it, basic WCF stuff). What I will do is post the relevant code inside the service that deals with subscribers.
Service Implementation
The service maintains a list of subscribers which take the form of the IMovieServiceCallback. The three key methods for dealing with the subscribers are thus:
bool IDuplexService.KeepAlive()
{
return true;
}
void IDuplexService.Subscribe()
{
var callback = OperationContext.Current.GetCallbackChannel<IMovieServiceCallback>();
if (!_subscribers.Contains(callback))
_subscribers.Add(callback);
RemoveDeadConnections();
}
void IDuplexService.Unsubscribe()
{
var callback = OperationContext.Current.GetCallbackChannel<IMovieServiceCallback>();
if (_subscribers.Contains(callback))
_subscribers.Remove(callback);
RemoveDeadConnections();
}
The KeepAlive is the simplest thing; just return a boolean. All we really care about is hitting the service to keep it open, and we do that with the aid of a timer in the client’s proxy (which we’ll get to later on).
Where things get interesting is how we handle the manipulation of data. In a one-way service the client would ask the service to create a new Movie and persist it. Once that operation was complete, the client would then proactively ask the service for an updated list of Movies. The client does all the work in this situation, making the requests. That’s fine for one client, but if other clients want to know when the data changes, they have to poll the service.
With a duplex service we tend to make a request of the service and then forget about it; the service will update us (and every other client) when its ready. So deleting a Movie looks like this:
public void Delete(Movie movie)
{
_repository.Delete(movie);
_movieCache = _repository.FindAll();
UpdateSubscribers();
}
The service delegates to a Repository to handle the delete, updates its internal cache, and then makes a call out to all the subscribers, in essence telling them, “Hey, the data has changed. Update yourself”.
Updating the subscribers then becomes a matter of looping through them and calling the method on the callback interface:
private void UpdateSubscribers()
{
for (int i = _subscribers.Count - 1; i >= 0; i--)
{
if (((ICommunicationObject) _subscribers[i]).State == CommunicationState.Opened)
{
_subscribers[i].MoviesChanged();
}
else
{
((ICommunicationObject) _subscribers[i]).Abort();
_subscribers.Remove(_subscribers[i]);
}
}
}
We are doing one extra step here: getting rid of delinquent subscribers. You see, there’s no easy, event-driven way to determine when a client has faulted or disconnected in a non-nice way. So the best plan is to periodically prune off bad subscribers. In my service, I do this whenever the data changes, and whenever a client subscribes or unsubscribes. It helps keep the subscriber list clean.
Client Proxy
With the service side of things mostly out of the way it’s time to move on to the client. Here I’ve manually created a client proxy (not using svcutil.exe). The proxy class implements the methods from IMovieService. Beyond the methods on the IMovieService interface, the proxy has a few responsibilities:
- Create the DuplexChannel and establish the connection to the service.
- Subscribe to the service.
- Create a Timer and fire the KeepAlive periodically.
- Unsubscribe from the service when shutting down.
- Respond to callback events from the server and re-fire them in a chain-of-command style pattern to the client.
Connect handles the first three responsibilities:
public void Connect()
{
_movieServiceCallback = new MovieServiceCallback();
_movieServiceChannelFactory = new DuplexChannelFactory<IMovieService>(_movieServiceCallback, _movieServiceEndpointConfigurationName);
_movieService = _movieServiceChannelFactory.CreateChannel();
((IContextChannel) _movieService).OperationTimeout = new TimeSpan(0, 0, 0, 30);
_movieService.Subscribe();
_movieServiceCallback.OnMoviesChanged += MoviesChanged;
_timer = new Timer(60000);
_timer.Elapsed += TimerElapsed;
_timer.AutoReset = true;
_timer.Start();
}
A Disconnect method handles the fourth responsibility. Responding to the service is handled by the MovieChanged event, which simply re-fires it:
private void MoviesChanged()
{
if (OnMoviesChanged != null)
OnMoviesChanged();
}
The other thing that I have the proxy do is make asynchronous calls to the service for methods that I know should be asynchronous. An example is Delete():
private delegate void DeleteDelegate(Movie movie);
public void Delete(Movie movie)
{
DeleteDelegate deleteDelegate = _movieService.Delete;
AsyncCallback callback = AsyncCompleteMethod;
deleteDelegate.BeginInvoke(movie, callback, null);
}
private void AsyncCompleteMethod(IAsyncResult ar)
{
}
When the client makes a call to delete, it’s made asynchronously, and the client can immediately return. The UI doesn’t lock up and life goes on for the client. When the service is done processing the delete it will update the subscribers. That’s when they’ll have to respond in a way that doesn’t lock the UI or crash the program.
Client
In my view’s presenter class I take a dependency on the IMovieService interface. By way of StructureMap, the presenter gets the MovieServiceProxy, and we wire up to it’s OnMoviesChanged event:
private IMovieService _movieService;
public ShellPresenter(IMovieService movieService)
{
_movieService = movieService;
}
public override void OnViewReady()
{
base.OnViewReady();
((IMovieServiceProxy) _movieService).OnMoviesChanged += MoviesChanged;
MoviesChanged();
}
The MoviesChanged method just queries the service for the list of Movies (which are conveniently cached in the service, so the service isn’t hitting the database every time a client requests the list).
private void MoviesChanged()
{
View.Movies = _movieService.FindAll();
}
And this is where the trouble occurs if you don’t handle it correctly. We’ve just had what amounts to a background thread inform us to update our view. If we try and do this directly we’re going to get some unpleasant behavior in our UI. So we let the View handle this properly:
public delegate void UpdateMovieListDelegate(IList<Movie> movies);
public IList<Movie> Movies
{
set
{
if (InvokeRequired)
{
var args = new object[1];
args[0] = value;
BeginInvoke(new UpdateMovieListDelegate(UpdateDataGridView), args);
}
else
{
UpdateDataGridView(value);
}
}
}
private void UpdateDataGridView(IList<Movie> movies)
{
_dataGridView.DataSource = null;
_dataGridView.DataSource = movies;
}
InvokeRequired is a property on Controls, and it’s a convenient way to determine if the update is coming from another thread. If so, we can launch the operation asynchronously on the proper thread, in this case, the UI thread, since controls in .NET can only be updated by the thread they were created on.
Real-time, client-server type applications aren’t terribly difficult to deal with, they just require a different mindset in regards to when things get updated. And then one just has to utilize the asynchronous tools that the .NET framework has provided to make sure things get done in a way that doesn’t cause your application to hang or crash.
