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:
- The
Redirector
service
- The "Server" Channel Sink
- 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;
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.