Five Pitfalls of the Channel Model, Part 2

In yesterday's post, we looked at the first three subtle rules, aka pitfalls, of the channel model.  Today's post covers pitfalls four and five.  A pitfall is something that has significant negative consequences and no clear indication in the code that you're doing something wrong.  I wish we had fewer pitfalls because then anyone could pick up and use the channel model with confidence.  However, a lot of these pitfalls are the result of providing you with power and flexibility in other areas.  We try very hard to hide the pitfalls from you when you're using contracts and the Service Framework.  Using the channel model directly is a tradeoff, like using assembly language.  There are times when it's the right solution to the problem, but you're giving up safety in exchange for more freedom.  At least with managed code though, you don't have to give up that much safety to get things done.

Pitfall #4: Actual maximum may be smaller than it appears

We let you specify a lot of different types of limits to restrict resource consumption, but we can never guarantee that you can actually hit those limits.  Setting the limits low protects you from Denial of Service (DOS) attacks at the cost of sometimes turning away legitimate traffic.  We've been very conservative with the default settings to keep you safe out of the box.  There are real world scenarios where you have to relax the limits to get your work done.

Some people are a little too relaxed with the limits.  You have to be realistic about the computational resources you can afford to spend.  Even if you set a very long timeout for an operation, we may give up before that if things are failing.  Even if you permit thousands of connections, you may not have enough memory, CPU, or bandwidth to talk with all of those clients before they die off.  Once your server hits full load, there are situations where it can begin to degrade very rapidly as you try to add more load.  And, as I pointed out in an earlier post, even if you permit ridiculously large message sizes, there are a lot of factors preventing you from successfully sending messages that big.  The moral of this story is that while the default settings leave a lot of headroom in production environments, there are limits to how far you can push your limits.

Pitfall #5: Complain if you don't want to do something

The last pitfall that I want to point out in this edition is that you always have to remember that we're all in this together.  Your service limits what clients can do by providing a restricted set of verbs to act on.  A service can validate client requests before taking action.  The code running behind your service is inside this trust boundary.  The channel model has rules you must follow, such as the object state machine.  There are ways to indicate that a problem has occurred and then there's also ways to simply misbehave.  At the channel model level, we can't do much to protect a misbehaving service from itself.  If you're lucky, your service gets caught breaking the rules without much penalty.  Sometimes, the service just dies and gets restarted.  Don't rely on this.  Make sure you follow the rules of the game, and we'll do our best to make sure that the rules actually work like we claim they do.

Next time: Using the Base Classes to Build Channels

Comments

• Anonymous
  April 04, 2006
  Although the WCF channel model has a relatively simple set of APIs, it has a very subtle set of rules...