The next step in our custom transport walk-through is to create our channel managers. This includes an IChannelFactory for our client side channels, and an IChannelListener for our service-side channels.

Both IChannelFactory and IChannelListener derive from IChannelManager. IChannelManager is responsible for tracking channels that are created or accepted. IChannelManager also has a property to control the MessageVersion supported for Messages sent or received on its channels. Lastly, it requires you to specify a Scheme to use for message addressing.

Which leads me to a crucial aspect in defining a channel, namely: what is your addressing model?

For layered channels, the addressing model is simply that of the channels they are layered on top of. Such implementations look like:

For transport channels, it’s an area that takes some thought. While HTTP has a pre-defined syntax and semantic, when writing a new transport you need to define both of these. Concretely, this includes a scheme and its associated URI syntax. This work is closely related to how you bind your protocol to SOAP.

The first item to consider is how your client Channels will resolve the URI. For example, HTTP takes the host name and TCP port of the URI (based on the defined URI grammar), uses DNS to resolve the host name into an IP Address, establishes a TCP connection to the resulting (IP Address, port), and sends an HTTP request using the path portion of the URI in our POST request.

The second factor in your URI design is how to match an incoming URI to an IListenerFactory (which will dispatch to a service). IListenerFactory URIs are broken down into 2 parts: a base address and a relative address. The base address is defined by your hosting environment (ServiceHost<T>, IIS vroot, etc). Individual endpoints then define a simple relative address. Note that an endpoint can be configured with a full URI, but this is only necessary in a few corner cases. This model allows for the host to be decoupled from its endpoints, and also allows the transport to optimize the network resources it uses (i.e. we only require at most one per base address, and can share that resource among relative endpoints).

Given these requirements, we define our URI syntax for UDP as:

For example: soap.udp://localhost:7000/service/endpoint

Our UdpOutputChannel will take the hostname (localhost) and convert it to an IP Address:

We will then use the resulting IP Address along with the UDP port from the URI (7000), construct a UDP socket to that remote endpoint, and set:

When our UdpListenerFactory (which is on the receiving end of the UDP socket) deserializes the message, it will compare the incoming message.To against its Uri and only accept the message if the two values match. More advanced implementations could factor out the listening socket into a shared app-domain wide resource that dispatches to the appropriate UdpListenerFactory based on the To of the incoming message.

With our transport addressing model crisply defined, we continue on to actually sending and receiving Messages over UDP!

A major source of confusion with Indigo Beta 1 is how to shut down our communication objects, so I’m going to drill further into this topic. First, I must note that this area is under review for Beta 2. We understand there are some inconsistencies between our usage of IDisposable and its usage by other parts of the .Net Framework. But the CTP bits are what you have to work with for now, so I will do my best to explain them 🙂

When I talked about the common state machine in Indigo, I neglected to point out that ICommunicationObject derives from IDisposable. This gives you a third option (in addition to our Close() and Abort() methods) for shutdown. It also allows you to use any ICommunicationObject with the C# using statement.

In the CTP bits, Dispose == Abort. Or put another way, Dispose != Close. This is a point worth re-iterating. Dispose will rudely abort your object.

So when you are done with an ICommunicationObject, what should you do?

First you should call Close(), which will flush any outstanding buffers, acknowledge outstanding data, and provide a graceful shutdown. This is similar to what happens when you call Stream.Close() or XmlWriter.Close(). Then you should make sure that Abort/Dispose is called if anything fails (i.e. throws an exception). This way any heavyweight network resources are released in an eager fashion.

Which leads to code like the following:

Before we dive into implementing our Channels, it’s important to first understand the lifecycle of communication objects in Indigo. These include our Channel Layer objects (IChannel, IChannelFactory, and IListenerFactory), as well as Typed Layer objects (ServiceHost, ServiceSite, EndpointListener).

All such objects derive from ICommunicationObject, and have a common state machine.

There are 5 states represented by the CommunicationState enum:

• Created — This is the state of an ICommunicationObject when it is first instantiated. The object may be configured in this state (e.g. properties can be modified, events registered, etc). No I/O occurs in this state.
• Opening — Objects transition to this state when ICommunicationObject.Open() is called. At this point properties are made immutable, and I/O may begin. This transition is only valid from the Created state.
• Opened — Objects transition to this state when the open process completes. This transition is only valid from the Opening state. At this point the object is fully usable for transfer.
• Closing — Objects transition to this state when ICommunicationObject.Close() is called for a graceful shutdown. This transition is only valid from the Opened state.
• Closed — In the Closed state objects are no longer usable. In general, most configuration is still accessible for inspection purposes, but no communication can occur. This state is equivalent to being disposed.

There are events that fire for each state transition. ICommunicationObject also has an Abort() method that can be called at any time. This will cause the object to transition immediately from its current state into the Closed state. Abort() indicates that any unfinished work will be rudely terminated (Exceptions are likely in this case).

With this background knowledge in place, we can now go into detail about writing our factories.