Manually Injecting a ListenUri

The ListenUri is a three-part setting on the BindingContext that gives the server-side address of a connection. The ListenUri has a base and a relative address, plus a mode switch. The mode switch controls whether the uri should be used as-is or whether parts of the uri have been left unspecified and need to be automatically generated. A common automatic address generation scenario is picking an unallocated network port.

There are only a few places where the ListenUri is actually used. One spot is in the transport, which needs to construct a uri for the remote address. The spot that I'll actually talk about though is the composite duplex channel. The composite duplex client channel uses the ListenUri for the backchannel address. I've already covered the basics of composite duplex and how the ListenUri factors into the backchannel construction process.

One of the interesting things about the composite duplex channel is that it has a partial fallback for the ListenUri, described in the article above. The ClientBaseAddress setting on the composite duplex binding element lets you specify a base address if the ListenUri is not provided. However, there's no equivalent ClientRelativeAddress that lets you complete the ListenUri. Therefore, if you use this fallback, then you'll always get some randomized component in your backchannel address. You generally want a randomized address because the backchannel address has to be unique across all of your current composite duplex clients. Having a randomized address doesn't work though when you need to allocate a resource with a particular name for the backchannel. MSMQ is an example where randomized addresses don't work because you need to allocate a queue whose name is tied to the backchannel address.

When you're programming against the channel model, working around this situation is not difficult because you own creating the binding context. This means that you have an opportunity to directly set the ListenUri. If you are using an automatically generated proxy client like most people do, then you have no opportunity to set the ListenUri. The proxy takes the configured binding and instantiates a copy, including the binding context, automatically. This is entirely hidden from the proxy client user. There are mechanisms for passing information to the channel construction process, called binding and channel parameters, but there is no binding parameter that corresponds to the ListenUri on the binding context.

With no way for the proxy client user to access the binding context or ListenUri, how do you use composite duplex with a non-randomized address? It turns out that you need to be creative intercepting the binding context before the composite duplex binding element gets a chance to see it.

Next time: ListenUriBindingElement

Comments

• Anonymous
  December 06, 2006
  This was a bug that we found a few weeks before V1 shipped but it was not deemed severe enough to fix