Mapping Channels to Shapes

When you build a channel factory or listener, you have to specify a TChannel parameter that describes the shape of the channel you want to build. In most cases, you don't have a lot of choices for the channel shape, although conceivably any subset of the possible channel shapes might be available depending on how you've configured your factory or listener.

That's not very helpful, so let's be specific and look at what our built-in channels support. I'll deviate a bit from usual by covering how the final release is expected to behave rather than how the latest public release does behave. This topic isn't meaty enough to be worthwhile revisiting in the future.

The NamedPipeTransportBindingElement and TcpTransportBindingElement change shape depending on whether the transfer mode is buffered or streamed. When buffered, both the factory and listener for these transports requires the IDuplexSessionChannel channel shape. When streamed, the factory requires the IRequestChannel channel shape and the listener requires the IReplyChannel channel shape.

The HttpTransportBindingElement doesn't change with the transfer mode. The factory always requires the IRequestChannel channel shape and the listener always requires the IReplyChannel channel shape. Previously, the HTTP transport cheated a bit by offering an IInputChannel and IOutputChannel option even though HTTP is inherently request-reply. Read on to find out what to do if you were using this feature.

The OneWayBindingElement is used to change one of the bidirectional channel shapes into a one-way channel shape (the naming is very clever). The factory feeding into the OneWay factory must provide either the IDuplexSessionChannel or IRequestChannel channel shape. The OneWay factory always requires the IOutputChannel channel shape. The listener feeding into the OneWay listener must provide either the IDuplexSessionChannel or IReplyChannel channel shape. The OneWay listener always requires the IInputChannel channel shape.

Finally, the CompositeDuplexBindingElement is used to logically associate an IInputChannel and IOutputChannel. On the factory side, both the CompositeDuplex factory and the underlying factory require the IOutputChannel channel shape. On the listener side, both the CompositeDuplex listener and the underlying listener require the IInputChannel channel shape. You'll notice that none of the transports mentioned above offer up an IInputChannel or IOutputChannel, so you'll need to make use of a one-way conversion at some point to build the composite duplex.

Next time: Inside the Standard Bindings: WSDualHttp

Comments

• Anonymous
  June 21, 2006
  I've talked about the framing that goes on in the network stack before, but today's topic is a case where...
• Anonymous
  August 30, 2006
  The CompositeDuplex channel is one of the two shape-changing channels that we’ve included in the product...