Share via


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

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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

Comments

  • Anonymous
    June 30, 2006
    PingBack from http://blogs.msdn.com/drnick/archive/2006/06/29/650583.aspx
  • Anonymous
    July 05, 2006
    First of all, Happy Independence Day to all in the US! I have a lot to list here but I will likely get...
  • Anonymous
    July 07, 2006
    The autoposter ate today's regular post so I decided to fill this space with a quick Q & A about...
  • Anonymous
    July 13, 2006
    The comment has been removed
  • Anonymous
    July 13, 2006
    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.
  • Anonymous
    October 17, 2006
    The comment has been removed
  • Anonymous
    December 04, 2008
    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