Right now there are two things that are consuming my life at work. The first is flushing out bugs and polishing off the final details of Indigo Beta 2. In the transports area you’ll see a lot of new HTTP functionality in Beta 2, including HTTP Streaming, cookie support, and fine grained extensibility to support RESTful scenarios. And we’ve made usability improvements across the board based on Beta 1 feedback. Keep the comments/bugs coming and let us know what still needs work for your scenarios!

The second is preparing for Microsoft’s Professional Developer Conference, affectionately known as “PDC”. PDC is Microsoft’s forward-looking developer conference (i.e. what’s coming as opposed to what’s shipped), and has a ton of breakout sessions about Avalon, Indigo, Whidbey, Office, Vista, and more.

If you’re going to be at the PDC, you should come see Yasser and I lift the curtain on Indigo’s Channel Layer. We’ll go over many of the intricacies involved in writing custom transports and custom layered channels. You’ll also be able to pepper me with questions at any point during the conference.

The official abstract describes our talk as follows:

Windows Communications Foundation (“Indigo”): A Deep Dive into Extending the Channel Layer
One of the most powerful ways you can extend the Windows Communications Foundation (formerly codename “Indigo”) is by teaching it to speak additional protocols and transports. Want to use the Windows Communications Foundation to talk directly to a system that understands only proprietary protocols? No problem. Want to use the Windows Communications Foundation to build reusable SOAP-based protocols? We have you covered. This session shows you how to write a custom Windows Communications Foundation transport that can be used as seamlessly as the built-in transports (e.g. HTTP and TCP). It also shows you how to write a custom SOAP-based protocol that composes with the other built-in protocols.

I promise it will be entertaining (if I’m wrong you can bring tomatoes). See you there!

A giant leap forward in Windows HTTP technologies was introduced with Windows Server 2003, namely http.sys. Http.sys includes a kernel-mode listener that can dispatch to any process on the machine. This was great news to those of us that wanted to share port 80 with other applications (IIS for example). It also has a comprehensive namespace security mechanism which admins can use to delegate sections of the global hierarchical directory space to less-privileged accounts. IIS 6.0 (which shipped with Server 2003) was built on top of http.sys and so did not require exclusive access to its configured port #s.

Indigo’s standalone HTTP IChannelListeners are built on top of http.sys. That means that if you are not hosted in IIS, your process will need to have access to any http addresses that your ServiceHost is configured with. If the process is not running as admin you will need to add a reservation using httpcfg.exe. Alternatively, you can call the HTTP configuration APIs, such as HttpSetServiceConfiguration, directly.

There is one more wrinkle when working on XPSP2. While http.sys was backported to XP as part of Service Pack 2 (yay), IIS 6.0 was not (boo). This means that if you have IIS running on your XP box, then you are using IIS 5.1 which is built on top of a listening socket and thus owns port 80. If you try to open a Service using port 80 while IIS is running you will get the following error:

AddressAlreadyInUseException: HTTP could not register URL http://+:80/myService/ because TCP port 80 is being used by another application.

You have 2 choices to remedy this situation:

1. Stop IIS (using “net stop w3svc”)
2. Setup your service to use a different port#

Setting up a different port# is usually a simple matter of changing your Service’s URL. However, a more subtle variation of this failure occurs for clients that use WsDualHttpBinding (or a custom binding with CompositeDuplexBindingElement and HttpTransportBindingElement). Your indication here is the inclusion of “Temporary_Indigo_Addresses” as in:

AddressAlreadyInUseException: HTTP could not register URL http://+:80/Temporary_Listen_Addresses/51E705D5-E7B5-472B-B6B9-A6A60FE93B7A/ because TCP port 80 is being used by another application.

When your client is using a Dual binding, then the system creates a temporary address to listen on, in order to establish two-way communication over two one-way channels. For HTTP, this address by default is setup on a subtree of http://+:80/Temporary_Indigo_Addresses. This has the advantage of being a namespace pre-ACLed by Indigo for access by all processes. You can override this default through the ClientBaseAddress property on WsDualHttpBinding and CompositeDuplexBindingElement. You can do this either through code:

binding.ClientBaseAddress = "http://localhost:8000/myClient/"

or config:

<wsDualHttpBinding clientBaseAddress="http://localhost:8000/myClient/"/>

Good luck on future port conflict avoidance!

The final piece that we need to add to our Transport is configuration support. To expose our transport through config, we need to implement two configuration sections.

Binding Element Extension Section

The first class we add is to configure UdpTransportBindingElement. This is so that custom binding implementations can include udp. In UdpTransportSection we define our configuration section name (how we are referenced from config), the type of our binding element, and how to create our binding element; all with just a few simple overrides. We can then register our extension section in a .config file as follows:

And it can be referenced from custom bindings to use UDP as their transport:

Binding Section

The second class we add is to configure SampleProfileUdpBinding, our “standard binding”. Through SampleProfileUdpBindingSection we expose this binding to the configuration system. Most of the methods delegate to SampleProfileUdpBindingConfigurationElement, which derives from StandardBindingConfigurationElement.

SampleProfileUdpBindingConfigurationElement has properties that correspond to the properties on SampleProfileUdpBinding, and functions that map from the ConfigurationElement to Binding and vice-versa.

Finally, we need to override the OnApplyConfiguration() function in our SampleProfileUdpBinding:

To register this handler with the configuration system, we add the following section to a .config file:

It can then be referenced from serviceModel config:

The result is a completely functional third party transport that can be used in any Indigo program!