Transport Channels

Let's shift gears for a bit and talk about transport channels now as opposed to protocol channels. Everything that was said yesterday for channel stacks is still true when we add transport channels to the picture. Everything that was said yesterday for protocol channels is essentially going to be reversed.

Here are the essential points that change when we move from protocol channels to transport channels.

Protocol channels have two sides: an inner and an outer channel.

Transport channels have one side. The inner end of the transport channel connects to the network.

Obvious corollary:

Protocol channels move messages up and down the channel stack.

Transport channels move messages to and from the network.

More obvious corollary:

Every channel in the channel stack but the bottommost one is a protocol channel.

The bottommost channel in the channel stack is a transport channel.

Protocol channels work on messages that are XML InfoSets.

Transport channels operate on a stream of bytes.

As we go through the architecture, you'll notice that transport channels are the only time during messaging that we have actual bytes. This is a necessity as traditional networking interfaces, such as sockets, have no idea how to send an XML message. The only data type that these interfaces rationalize about is byte arrays. The transport channel is the component that is responsible for converting between XML messages and byte streams. There is a standard pattern for delegating this behavior from transports to an external component called a message encoder. A message encoder is an interface that allows third-party developers to plug conversion functionality into a transport. You can choose to either use or ignore this model, although I'd strongly suggest supporting encoders if your transport permits multiple byte encodings for an XML message.

The transport channel is also responsible for doing any post-processing on the byte stream. For example, there is a common step called framing in which the payload data is embedded inside a structured format for sending messages. Unlike message encoders, there is no standard interface for applying framing to a byte stream. The current transports that support framing build their framing protocol directly into the transport channel.

We're going to take a break from the channel development series for a day tomorrow. When we come back, there will be some catch-up for illustrations and then we go directly into the second topic to overview WCF architecture.

Next time: Tuning Contracts for Performance

Comments

  • Anonymous
    February 22, 2007
    There are only two kinds of channels in the world. Today we'll talk about protocol channels. Tomorrow

  • Anonymous
    March 13, 2007
    This pair of articles marks the checkpoint between the "big picture" introductory segments and the segments