Tag Archives: channel

Fixed Ideologies and Message exchange patterns

I had never thought that I would actually write about a topic like this but sometimes you want to organize your thoughts and have an opinion on things. Being in the performance team for WCF has got me used to a plethora of message exchange patters which we lovingly refer to as MEP. There exists a broad spectrum of coding and implementation styles which we see day in an day out. There are those that are extreme and elaborate and overwhelmingly flexible and also those that are so convoluted and rigid that its almost close to assembly.

Its good to know know what message exchange patterns would be most suited for his or her needs. I think its an overkill to adopt a strategy where your application will force itself to use only a single message exchange patter. For example an ideology like “We will do only rest style request reply throughout our system” The number of layers we need to add in order to align ourselves with a philosophy like this would probably outweigh the benefits that it provides, specifically in scenarios that aren’t suited for patterns like these.

There is a really nice article on MSDN listing out 6 message exchange patters http://msdn.microsoft.com/en-us/library/aa751829.aspx To quickly reiterate they are Datagram/Request-Reply/Duplex and 3 of these with sessions on top.  You can think of a session like a logical abstraction to say that the message is a part of a conversation. This has nothing to do with asp.net sessions and it is a way for WCF to correlate messages.

My experience it is generally more helpful to classify your problem and see what pattern really helps your issue and then slap on the contracts and protocols rather than fixing on the protocol/MEP and then forming a solution around that. I choose not to be an advocate of any particular style but I am against protocol fanatics who are inflexible and who believe that there are a fixed set of choices for certain types of scenario.

Systems are organic and so its hard to freeze implementations. The fact is patterns are similar too. Today you might be ok with TCP but there is nothing stopping you from switching to queues. As the system grows and there would be solutions you put in place to facilitate this kind of a change. Layers get added and MEPs also change.

If you have any questions on how to make a choice I would gladly try to help out.

The Channel Pump

Deep dive – Nicholas Allen’s talk on WCF performance and Scale – PowerPoint DeckWebcast

From the above talk you get an idea of the pull and the push model and a combination of these for certain channels. This defines how the message will be received on the transport and how they will be dispatched. Consider a pump as a loop doing some work. A pump works off a queue which it would push work on for the next layer or pulls work off when there is some work to be done.

Considering a very common scenario like basic http where a message would arrive on the transport. The flow would consist of 2 loops.


Dispatcher/Message Pump

1. Dispatcher gets a message. It has available resources and will dispatch the operation(Application)
2. Dispatcher then tells the pump that it can accept the next message.

Channel Pump

1. Pump registers that it can take pull a message.
2. Message arrives and Transport pushes the message to the dispatcher.

All channels affect how messages arrive and how they would be dispatched. We make a fundamental assumption in WCF that channels would always be fast. This is because of the fact that the channel is your infrastructure and it makes sense to put any heavy work to the application layer and not the channel layer.

So general rule of thumb – Do not do blocking or heavy work in your channels. Pass on the work to the upper application layer.

You should think of your channel as gate to your dispatcher and you don’t want to block the gate from letting the next person in. Hence bottom line is that a slow channel is a suboptimal channel.