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:
public override string
return InnerListenerFactory.Scheme; }
public override void SetUri(Uri uri)
public override void SetUniqueUri()
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:
soap.udp:// host [":" port] path-absolute
where host, port, and path-absolute are defined in the ABNF of RFC 3986.
Our UdpOutputChannel will take the hostname (localhost) and convert it to an IP Address:
remoteIP = IPAddress.Parse(remoteAddress.Uri.Host);
IPHostEntry hostEntry = Dns.GetHostEntry(remoteAddress.Uri.Host);
if (hostEntry.AddressList.Length > 0)
remoteIP = hostEntry.AddressList;
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:
message.To = RemoteUri (soap.udp://localhost:7000/service/endpoint).
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!