Click here to Skip to main content
Click here to Skip to main content

.NET Remoting Message Redirection Channel Sinks

, 20 Jun 2003
Rate this:
Please Sign up or sign in to vote.
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:
    <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.

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

About the Author

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

 
GeneralMy vote of 1 PinmemberLavrekho21-Aug-11 2:20 
GeneralTimes out Pinmembertnvcode30-Sep-09 15:52 
GeneralRe: Times out PinmemberAlexsandro_xpt16-Apr-12 8:27 
QuestionCompression Sink there way? PinmemberAlexsandro_xpt9-Aug-09 11:56 
GeneralBecause of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed. PinmemberAlexsandro_xpt30-Jun-09 15:12 
GeneralRe: Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed. PinmemberAlexsandro_xpt6-Aug-09 13:40 
JokeIt Works! PinmemberSpungin8-Mar-09 19:11 
I cannot believe that Microsoft Remoting will not work through NAT by default. What is the point of a remotable object infrastructure that does not just 'work' between objects that can obviously communicate with each other. Thanks for the code!
GeneralZHI, please reply if you are still around... Pinmemberkdubious9-Aug-08 17:10 
QuestionIs their a way to get the client to not open a listening socket Pinmemberpiba6-May-08 10:41 
QuestionStarting client events from server PinmemberDamz19-Sep-07 7:13 
Generalserver not processing any request when client is not reachable Pinmembermanish barai23-Jun-07 1:40 
GeneralMore sample code requested Pinmemberboboruba28-Feb-07 0:12 
GeneralRe: More sample code requested Pinmemberpiba6-May-08 10:26 
GeneralTrying to make it work. PinmemberMihaiMarin20-Apr-06 1:59 
GeneralMore details please Pinmemberlangdeng17-Oct-05 19:32 
GeneralI found better stuff : www.dotnetremoting.com PinsussTcheck31-Jan-05 18:09 
GeneralRe: I found better stuff : www.dotnetremoting.com PinsussAnonymous7-May-05 14:09 
GeneralRe: I found better stuff : www.dotnetremoting.com Pinsusso922-Oct-05 18:26 
Generala small question Pinmemberqnguyenhoang@yahoo.com16-May-04 23:03 
Generalmistake Pinmemberqnguyenhoang@yahoo.com16-May-04 23:05 
GeneralSecurity Exception PinmemberGery Dorazio20-Aug-03 16:29 
GeneralRe: Security Exception PinmemberMadShad20047-Apr-04 21:22 
QuestionIs this solution really useful? PinsussBill200226-Jun-03 19:05 
AnswerRe: Is this solution really useful? Pinmemberzhi28-Jun-03 5:02 
GeneralRe: Is this solution really useful? Pinmember_Bill2002_28-Jun-03 8:07 

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

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

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 21 Jun 2003
Article Copyright 2003 by zhi
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid