.NET Remoting Message Redirection Channel Sinks

• Download source files - 5.79 Kb
• Download demo project - 25.4 Kb

Introduction

.NET remoting is a beautiful framework, but its most serious deficiencies preventing it from being useful in today's Internet environment, is that it requires each node to have a global IP, so direct TCP connections can be made. Other incomplete solutions aimed at this problem exist (GenuineChannel), but they use special transport channels (instead of the standard TCP/HTTP), with large amount of unproven custom code, thus make your code heavier and unstable. These solutions also do not let 2 objects both behind firewall call each other, either.

Reachability channel sinks provide a more lightweight, elegant solution. Remoting objects hosted by machines with only local IPs behind firewalls can be made reachable from anywhere (including those machines behind firewalls themselves), using standard transport channels, by a Message Redirector. The whole process is transparent from upper, logic layers. Asynchronous calls, one-way calls are also supported.

Advantages of .NET remoting

.NET remoting has the the following advantages:

• Separation of network-code from logic code.
• Advantage over WebService: Clients can receive events from server. More types can be passed. Higher throughput.

Although .NET remoting is designed to accommodate the need of Enterprise intranet applications, nothing prevents it from being used over the Internet, at least not security problems - it is free from security holes - buffer overrun is impossible in managed code in which .NET remoting framework is entirely written. .NET remoting is ideal for peer-to-peer applications, because it alleviate programmers from writing complex network code that manages complex network topologies.

How to use in your project

Configuration files

• For hosts who are behind firewall and need to expose objects:

  <appSettings>
    <add key="RedirectorURL" 
      value="tcp://Redirector's IP:Port/Redirector.rem" />
  </appSettings>
  ....
     <serverProviders>
       <provider type="Reachability.ServerSinkProvider, Reachability" />
         <formatter ref="binary" />
     </serverProviders>

• For hosts who need to call objects through Redirector:

  <clientProviders>
        <formatter ref="binary" />
          <provider 
           type="Reachability.ClientSinkProvider, Reachability" />
  </clientProviders>

• For Redirector:

  <wellknown mode="Singleton" 
          type="Reachability.Redirector, Reachability" 
      objectUri="Redirector.rem" />
  ...
           <channels>
             <channel ref="tcp" port="Redirector's Port" >
              <serverProviders>
         <formatter ref="binary" />
       </serverProviders>
       <clientProviders>
        <formatter ref="binary" />
       </clientProviders>
      </channel>
      
           </channels>

Code needed

Add reference of Reachability.dll to your project.

Hosts which need to expose objects via the Redirector must call Reachability.ServerSinkProvider.StartWaitRedirectedMsg() after RemotingConfiguration.Configure(), or after RemotingServices.Marshal(). The effect of this call is to start receiving messages from the Redirector.

How it works

There are already many articles on how .NET remoting works and on channel sinks, and I don't have time to repeat such descriptions here. The Reachability sinks have 3 components:

1. The Redirector service
2. The "Server" Channel Sink
3. The "Client" Channel Sink

Basically, server sink adds reachability information (i.e. via which Redirector can we send message to this object) to (ChannelData in ) the ObjRef. When this ObjRef is passed to somewhere, there, the client sink finds out that reachability information attached to the ObjRef, and instead of directly trying to connect to the object, it pass the call to the Redirector. The Redirector will deliver the call appropriately, provided the host which created the ObjRef is listening on the Redirector properly. (This is done by StartWaitRedirectedMsg()).

Here is the heart of the code that makes hosts behind firewall receive calls (without special transport channel):

public void RedirectRequest(Guid slot, bool oneway, 
     ITransportHeaders requestHeaders, byte[] requestStream, 
     out ITransportHeaders responseHeaders, out byte[] responseStream)
{
   SyncQueue q = reqs[slot] as SyncQueue;  
   if(q==null)reqs.Add(slot, q=new SyncQueue());
   q.Enqueue(new Message(requestHeaders, 
       requestStream, Thread.CurrentPrincipal, oneway));
   
   if(!oneway)
   {
      q = resps[slot] as SyncQueue;   
      if(q==null)resps.Add(slot, q=new SyncQueue()); 

      Response r = q.Dequeue() as Response;
      responseHeaders = r.responseHeaders;
      responseStream = r.responseStream;
   }
   else
   {
      responseHeaders = null;
      responseStream = null;
   }
}
.....
   static void WaitForRequest(object o)
   {
      Redirector r = Activator.GetObject(typeof(Reachability.Redirector), 
                     RedirectorUrl) as Reachability.Redirector;
      Redirector.Message m;
      try
      {
         while(true)
         {
            r.GetNextRequest(rdata.Slot, out m);
            if(m==null)break;
          // must place this sink after formatter before
          // server transport, so message goes into stream.
            IMessage respMsg;    

                ITransportHeaders respHeader;
                Stream respStream;
            ServerChannelSinkStack stack = 
                  new ServerChannelSinkStack();     
                stack.Push(new ServerSink(theSink),r);
     
               theSink.ProcessMessage(stack,null,
                 m.requestHeaders,
                 new MemoryStream(m.requestStream),
               out respMsg, out respHeader, out respStream);
               if(!m.oneway)
               {
                    r.ReturnResponse(rdata.Slot, 
              new Redirector.Response(respHeader, respStream));
           }
        }
     }
     catch(Exception e){
        System.Diagnostics.Trace.Write(e.ToString());
     }
   }

The node behind firewall will not listen for incoming calls, instead it calls GetNextRequest() and blocks till an incoming call arrives (like the Windows API GetMessage()). The Redirector is blocked until ReturnResponse() is called.

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here