WCF Duplex Messaging

2011-01-05T22:56:00.000-08:00

I am one of the moderators of the MSDN WCF Forum. One of the main areas of questions on the forum is duplex messaging – particularly using the WSDualHttpBinding. So instead of typing long messages repeating the same thing in answer to these questions I’ve decided to write this blog post to give a bit of background about duplex messaging and then discuss the options for bindings and common problems people have.
What is Duplex Messaging?

There are many ways that messages can be exchanged between two parties in a service based system: the client can send messages to the server and never get any back; the client can send a message and wait for a response; the client and service can send eachother messages without any pre-defined pattern; the client can send the service a message but not wait synchronously for a response and then then service can send a message back asynchronously; and there are many others. However, the first three of these are supported natively in WCF and are known as One-way, request/response and duplex.

So Duplex messaging is where, unsolicited, the client and service can send eachother messages. Most commonly this is characterized by the service sending the client “events” or notifications or progress of “interesting things”.
Duplex Contracts in WCF

To send messages to eachother the client and service must have an idea of what operations are available and what messages are sent and received during the communication. In WCF this idea is modelled by the contract. Now normally a contract just determines what functionality is available at the service. However, now the service is going to be sending messages to the client that the client isn’t specifically waiting for so it needs an idea of what messages the client can deal with. So we need a contract that models both directions of the conversation.

A bi-directional contract is modelled using two interfaces bound together with a ServiceContract – like this:

[ServiceContract(CallbackContract=typeof(IPizzaProgress))]

interface IOrderPizza

{

[OperationContract]

void PlaceOrder(string PizzaType);

}

interface IPizzaProgress

{

[OperationContract]

void TimeRemaining(int minutes);

[OperationContract]

void PizzaReady();

}

The import bit here is the CallbackContract that establishes the relationship between the service’s and client’s contracts.
Writing the Service

The service is implemented normally apart from two issues: firstly it needs to access the callback contract to be able to send messages back to the client; secondly the communication infrastructure (modelled by the binding) needs to be able to cope with duplex messaging. Firstly lets look at accessing the callback contract:

class PingService : IOrderPizza

{

IPizzaProgress callback;

public void PlaceOrder(string PizzaType)

{

callback = OperationContext.Current.GetCallbackChannel();

Action preparePizza = PreparePizza;

preparePizza.BeginInvoke(ar => preparePizza.EndInvoke(ar), null);

}

void PreparePizza()

{

for (int i = 10 - 1; i >= 0; i--)

{

callback.TimeRemaining(i);

Thread.Sleep(1000);

}

callback.PizzaReady();

}

}

The critical line here is calling GetCallbackContract on the OperationContext. This gives the service access to a proxy to call back to the client.

Now the service also needs to use a contract that is compatible with duplex messaging. WSHttpBinding is the default for the built in WCF projects but it does not support duplex messaging. People generally then move to the WSDualHttpBinding which is similar to the WSHttpBinding but does support duplex. I will go into more depth about bindings for duplex shortly but for now lets stick to this for now - it will work in our test rig on a single machine without issue.
Writing the Client

If the client is going to receive these messages it needs to provide an implementation of the callback contract. It can gets its definition from either a shared contract assembly or from metadata. If using metadata the callback contract will be named the same as the service’s contract but with the work Callback appended. It will also need to supply this implementation to the WCF infrastructure and it does this by wrapping an instance in an InstanceContext object and passing it to the proxy constructor. So here is the client:

class Program

{

static void Main(string[] args)

{

InstanceContext ctx = new InstanceContext(new Callback());

OrderPizzaClient proxy = new OrderPizzaClient(ctx);

proxy.PlaceOrder("Pepperoni");

Console.WriteLine("press enter to exit");

Console.ReadLine();

}

}

class Callback : IOrderPizzaCallback

{

public void TimeRemaining(int minutes)

{

Console.WriteLine("{0} seconds remaining", minutes);

}

public void PizzaReady()

{

Console.WriteLine("Pizza is ready");

}

}

Running the service and the client will have this working quite happily – so it would seem that duplex messaging and WCF works very well … so why on earth do people keep asking questions about it on the WCF forums?
It Worked on My Machine but Broke when we Deployed It!

Ahh well you probably did the thing that is obvious but almost always a bad idea. You went and chose WSDualHttpBinding as your duplex binding. To understand why this is a bad idea we need to dig a little deeper into how the WSDualHttpBinding works. HTTP is a unidirectional protocol: the client makes a request and the server sends a response. There is no way for a server to initiate an exchange with the client. So how on earth is duplex messaging going to work because it requires exactly this facility? Well the “Dual” in the name is significant, the WSDualHttpBinding actually consists of two connections: one outbound from client to server and one inbound from server to client – this second connection may already be ringing alarm bells with you. The are a two big problems with inbound connections to a client: firewalls very often block inbound connections to clients; the client may not be reachable from the server, it may be using NAT translation behind a router and so cannot be contacted without port forwarding being set up on the router. Both of these issues are showstoppers in real network topologies. You can take some small steps to help – you can specify what port the client should listen on for example by using the clientBaseAddress property of the WSDualHttpBinding. This means the network admin will only have to punch one hole in their firewall (but lets face it, network admins don’t allow any holes to be punched in the firewall).

So if you really shouldn’t use WSDualHttpBinding for duplex, what should you use instead? Well NetTcpBinding supports duplex out of the box and the nice thing about this is that the outbound connection that it establishes can also be used be used for inbound traffic – suddenly we don;t have the inbound connection firewall/NAT issues. “But hold on, isn’t NetTcpBinding for intranet? I’ve read books that tell me that in their ‘which binding should I use?’ flowcharts!” Well it turns out those flowcharts are talking rubbish – NetTcpBinding works very happily over the internet, its just not interoperable by design. “Aha! but I need interop so WSDualHttpBinding is for me!” Well unfortunately not, NetTcpBinding is non-interoperable by design, WSDualHttpBinding is non-interoperable despite its design. From the name it would suggest interoperability but Arun Gupta from Sun wrote this excellent post describing why it wasn’t.

So now seeing that we really are not talking about interop anyway, NetTcpBinding is far more useful than WSDualHttpBinding. Its not bullet proof, if the firewall only allows outbound port 80 but also allows inbound port 80, then WSDualHttpBinding would work where NetTcpBinding wouldn’t – but in this situation we’re really talking server to server and so I’d argue its probably better to roll your own bidirectional communication with two standard HTTP based connections.

The final option you have for duplex communication is to add a piece of infrastructure into the mix. The .NET Services Service Bus (part of the Azure platform) allows two parties to exchange messages both making outbound connections – potentially even using HTTP port 80. The two outbound connections rendezvous in the Service Bus which mediates their message exchanges. If the receiver has had to use outbound port 80 then it polls to receive message bound for it.
It Worked for the First 10 Clients and then the Rest Timed Out!

Irrespective if which of the standard bindings you are using, duplex assumes a constant relationship between proxy and service. In WCF this idea is modelled by the concept of session. All duplex bindings require session. A while back I wrote in some detail about sessions. You will have to either put up with increasing the session throttle (see the linked article for details) or roll your own custom binding that can do duplex without session – you can find an example of this here.
I Use the Callback While the Client is calling the Service and it Deadlocks!

This is because your client is probably a Rich Client GUI based application (Windows Forms or WPF). To understand why this is a problem we need to step back briefly and look at UI clients, threading and WCF threading. UI applications have a rule: you must only update the UI from the thread that created those UI components. In general a GUI application has one UI thread so anything that changes the UI needs to be done from that thread. .NET 2.0 introduced a new construct to simplify the process of a background thread updating the UI: SynchronizationContext. The idea is that a UI framework creates an implementation of a SynchronizationContext derived class that handles the mechanics of marshalling a call on to the UI thread. An instance of this implementation is then made available on the UI and accessible via the SynchronizationContext.Current.

WCF adds more complexity into the mix by enforcing a rule that says “unless you tell me otherwise I will only allow one thread at a time into an object that I control”. You see this with singleton services that will only allow one call at a time by default. The same is also true of the callback implementation object – so WCF will only allow one active thread in the client at a time. So while WCF is performing an outbound call it will not allow an inbound call into the object. This causes the initial problem with the deadlock that the service’s callback cannot be dispatched while the client’s outbound call is in progress. To solve this we use the “unless you tell me otherwise” part of the above rule. You do this by annotating the callback implementation class with a [CallbackBehavior] attribute like this:

[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant)]

class Callback : IOrderPizzaCallback

{

public void TimeRemaining(int minutes)

{

Console.WriteLine("{0} seconds remaining", minutes);

}

public void PizzaReady()

{

Console.WriteLine("Pizza is ready");

}

}

But now there is another problem: by default WCF will attempt to dispatch using an available SynchronizationContext. The problem with this callback is the UI thread is already blocked in an outbound call. SO for the call to dispatch we need to tell WCF not to use the SynchronizationContext – again using the CallbackBehavior attribute:

[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Reentrant, UseSynchronizationContext=false)]

class Callback : IOrderPizzaCallback

{

...

}

Now the issue is of course that the call is going to be processed on a non UI thread so you would have to manually marshal any UI interaction using the SynchronizationContext.Post method.

Duplex messaging can be a useful message exchange pattern but in WCF there can be some unexpected issues. Hopefully this blog post clarifies those issues and demonstrates workarounds for them.

Ajax Website in Asp.net development

2009-11-20T10:34:00.000-08:00

ASP.NET AJAX is the free Microsoft AJAX framework for building highly interactive and responsive web applications that work across all popular browsers. The ASP.NET AJAX framework includes Server-Side ASP.NET AJAX, Client-Side ASP.NET AJAX, the AJAX Control Toolkit, and the jQuery library. ASP.NET AJAX enables developers to choose their preferred method of AJAX development, whether it is server-side programming, client-side programming, or a combination of both.

Easy development chat application is Ajax

easy to learn Ajax development in .Net

Please feel free to contact: me.rambhopal@gmail.com
for Ajax webapplication development

Web Development in Asp.net and Web Development in PHP

2009-11-20T10:18:00.000-08:00

Custom software development company, India offers offshore software development, Web development, custom ASP NET development, ASP.NET C# development, custom PHP development, custom application development services...

Web Development in Asp.net

Web Development in PHP

Please feel free to contact me.rambhopal@gmail.com
for web development applications

Classic ASP to ASP.NET Migration

2009-11-20T09:52:00.000-08:00

We make sure that our team of ASP Developers is updated with all these technologies and standards. If the requirement suggests that we use a specific standard, we make sure the standards specified in the requirements are looked upon else we go ahead and use the latest versions and standards. ASP development is an art that can only be accomplished by a few
Please feel free to contact me.rambhopal@gmail.com

Classic ASP to ASP.NET Migration

Its been years that we are monitoring the increasing popularity of .NET Application Services. This has resulted in the further development of the advanced features in website designing by the .NET developers. With this advancement in ASP.NET Web development , it has become more easier to develop the very user-friendly websites that are very impressive too.

The advancement of ASP.NET has outshone the ASP Classic application due to its advanced technology-based features. The ASP.NET developers find it more better in usage & development than the ASP Classic web development application in many different ways, which can be seen as below:

Stability

•In the ASP Classic mode there are more application crashes very easily as it runs under the inetinfo.exe process. This leads to many problems in the programming & consumes lot of time & resources.

•ASP.NET is absolutely crash-proof incase of any application failure. With this, the programming becomes much more advanced and easier as it is less time consuming.

Language Support

•Java script & VB are the only languages used in the ASP Classic Version.

•ASP.NET allows use of full server side programming languages & not just the scripting ones. The other languages that can be used are like C#, VB.NET, that allow the development of robust & very interactive web applications.

Compilation

•As Classic ASP is comprised of VB Script & Java Script interpreted at run-time, the compilation is carried out line by line. This results in some or the other inefficiencies at any point of time.

•ASP.NET allows to compile the code the very first time it is accessed. This compiled code then results in ASP.NET classes which allow the servicing of the subsequent page requests with the previously compiled codes.

Scalability

•ASP Classic version makes it difficult to update, maintain & replace the components used by the web pages, which means that the complete process of updates & upgrades becomes very lengthy.

•With ASP.NET the complete process of updating the components within a time-frame without even restarting the web server. This helps in achieving more stable applications comparing to the classic version.

With all these differences in the modules & structures, ASP.NET has been proved to be much more better and user-friendly than the ASP Classic Version in many ways. It has actually proved to be a boon for the ASP.NET application developers because of its exclusive features and has made the web development more efficient & effective in blooming the field of Business Development.

Hire dedicated asp, asp.net, php, c# programmers

WCF Duplex Messaging

Ajax Website in Asp.net development

Web Development in Asp.net and Web Development in PHP

Classic ASP to ASP.NET Migration