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 Scheme{
get { return InnerListenerFactory.Scheme; }}
public override void SetUri(Uri uri)
{
return InnerListenerFactory.SetUri(uri); }
public override void SetUniqueUri()
{
return InnerListenerFactory.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.
For example: soap.udp://localhost:7000/service/endpoint
Our UdpOutputChannel will take the hostname (localhost) and convert it to an IP Address:
switch (remoteAddress.Uri.HostNameType){
case UriHostNameType.IPv4:case UriHostNameType.IPv6:
break; case UriHostNameType.Basic:
case UriHostNameType.Dns:
IPHostEntry hostEntry = Dns.GetHostEntry(remoteAddress.Uri.Host);
if (hostEntry.AddressList.Length > 0)
{
remoteIP = hostEntry.AddressList[0];
}
// …
}
break;}
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!
hey man, good to see that the mac BU guys have such a strong sense of community, been browsing around on the blogs.
i’ll be honest i’ve had an alterior motive, but i was wondering if a new mac msn will be out ever, obviously mac represents a tiny percentage (less than 3%) of the computing market worldwide.. and is not gonna be a big earner, and for a product like messenger obviously less half of those mac users worldwide will use MSN.. so it obviously wont be a priority.
mac BU aparently is very secretive but there is a guy by the name of RJT spreading rumours on a site http://www.messengerformac.com and he’s got the attention of 24,000 people.. and it just seems like a scam to me, with no articles on the net anywhere except those originating from RJT, i just want to put the 24,000 peoples minds at rest by getting some facts, but of course everything is very secretive, so i understand if you cannot/don’t want to comment for whatever reason.
thanks in advance.
– spence.