Some Changes for Channels and Transports in the June CTP, Part 4

Nicholas Allen

30 Jun 2006 8:00 AM

Comments 7

Yesterday's post covered most of the big new features that were added in the latest release. Today I'll go through the rest of the new features that are smaller in scope although no less exciting.

When the channel stack is being built from binding elements, some binding elements want to know what elements are underneath of them so that they can properly configure themselves. Previously, there was no way for custom binding elements to get at this information. We made the RemainingBindingElements property on the binding context public so that your binding elements can work exactly the same as ours.
Transport stream upgrades frequently operate on a point-to-point basis, but the API for providing stream upgrades previously only gave the upgrade provider the final address of the connection. We've changed the interface for StreamUpgradeProvider so that upgrades can see both the endpoint address and the via address of the next hop.
It's now possible to disable the use of HTTP keep alive. We added a KeepAliveEnabled option to HttpTransportBindingElement with the default set to enabled, which was the old behavior. This option is only available on the binding element so you'll need to use a custom binding if you need to change this setting.
There's now a quota setting for how long a connection can take to authenticate. A client needs to send a few hundred bytes of data before the server has enough information to perform authentication. Previously, the client had the entire receive timeout in which to send this data. The header is often much smaller than a normal sized message and clients are anonymous until this information is processed. The ChannelInitializationTimeout on the binding element limits the amount of time a malicious client can tie up one of the connections for your server.

We also changed a few interfaces into abstract base classes although we didn't add any new functionality to those classes at this time. The IRequestContext interface is now the RequestContext class and the IStreamUpgradeBindingElement interface is now the StreamUpgradeBindingElement class.

I had a list of changes that I was hoping to get through during this week. However, the first two days ran a little bit long so there are still a few more items to cover. I'll run one more installment of this series on Monday and the next set of topics will start after the 4th of July holiday.

Next time: Some Changes for Channels and Transports in the June CTP, Part 5

Channels, Indigo, Bindings, Transports, HTTP, Channel Extensibility

Comments

Nicholas Allen's Indigo Blog : Some Changes for Channels and Transports in the June CTP, Part 3

30 Jun 2006 12:10 PM

PingBack from http://blogs.msdn.com/drnick/archive/2006/06/29/650583.aspx
Sam Gentile

5 Jul 2006 1:01 PM

First of all, Happy Independence Day to all in the US! I have a lot to list here but I will likely get...
Nicholas Allen's Indigo Blog

7 Jul 2006 12:13 PM

The autoposter ate today's regular post so I decided to fill this space with a quick Q &amp; A about...
Rich Crane

13 Jul 2006 11:26 AM

I am glad the WCF team added the support for disabling the HTTP Keep Alive feature. This really needs to be exposed from the out-of-the-box bindings that support HTTP. This is a typical scenario that people want to implement especially when dealing with load balance scenarios. Thoughts?
Nicholas Allen

13 Jul 2006 1:53 PM

The goal of bindings is to make things easier to use by restricting the possible choices that the user has. That's why we let you define your own precomposed bindings if you don't like ours. We've tried to keep the standard bindings as slim as possible so that new users don't have to look at a big pile of options and wonder what's safe to change. We felt that running with the default keep alive setting was so dominant, that it would be better to not put this setting on the standard bindings.

You can define your own custom binding based on one of the standard bindings

Binding b = new BasicHttpBinding();
BindingElementCollection be = b.CreateBindingElements();
HttpTransportBindingElement h = be.Find<HttpTransportBindingElement>();
h.KeepAliveEnabled = false;
CustomBinding c = new CustomBinding(be);

Or you could also define a new binding class that exposes this feature if you thought you had a lot of customers that would want this.
Nicholas Allen's Indigo Blog

17 Oct 2006 7:32 PM

Today's look at recent changes covers two cool new features. Better support out-of-the-box for building
Sam Gentile's Blog

4 Dec 2008 5:48 PM

First of all, Happy Independence Day to all in the US! I have a lot to list here but I will likely get interrupted any minute to go to the Shore and do holiday type stuff. Before, I start, I wanted to ask the readers a question. I am trying to get together