Click here to Skip to main content
15,867,453 members
Articles / Programming Languages / C#
Article

.NET Remoting Message Redirection Channel Sinks

Rate me:
Please Sign up or sign in to vote.
3.38/5 (20 votes)
20 Jun 20033 min read 111.8K   1.7K   27   30
An upper logic layer transparent way to redirect .NET remoting calls, enabling exposure of .NET remoting services behind firewall/NAT, to anywhere.

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:
    XML
    <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:
    XML
    <clientProviders>
          <formatter ref="binary" />
            <provider 
             type="Reachability.ClientSinkProvider, Reachability" />
    </clientProviders>
  • For Redirector:
    XML
    <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):

C#
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.

License

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


Written By
zhi
Researcher
United States United States
My name is Zhiheng Cao. I major in Eletronics Engineering, in University of Tokyo. I do part time jobs of computer programming and teaching high school students English and Mathematics.

CodeProject provided me with valuable information for my programming job many times in the past. I hope I can do my part by providing goodies I have.


Comments and Discussions

 
JokeIt Works! Pin
Spungin8-Mar-09 19:11
Spungin8-Mar-09 19:11 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.