Location: Home > Resources > DotNetRemotingProjects

.NET Remoting Projects

2002
Ingo Rammer

Update 08/11/2002: These projects are currently unsupported and will not work on .NET 2.0 without modifications. If you want a supported solution to this problem (and to many more), please head to www.genuinechannels.com for fully supported bidirectional TCP and HTTP channel. (NOTE: GenuineChannels is a commercial product which has been created by a different company to which we don't have any ties.)

Bidirectional TCP Channel

The package you are currently looking at contains a bidirectional TCP transport channel for .NET Remoting.

This channel aims to solve several problems related to events, callbacks and client-side sponsors when Remoting is used with clients behind NATs or Firewalls. Normally, with the built-in TcpChannel, Remoting tries to open a secondary connection from the server to the client whenever any of these features are used. This is a) necessary due to the TcpChannel's internal mode of operation in terms of "hard" request/response RPC and is b) problematic because normally, firewalls or NATs won't allow this secondary connection to be opened.

This BidirectionalTcpChannel works quite differently so that it allows the callback to employ the already exisiting connection which has been established by the client.

This is possible, because the channel internally works in an asynchronous, message oriented fashion so that request and response can share the same connection with a number of different simultanous requests and responses. The same connection will also be re-used for server-to-client callback requests and the client's response.

Download Information

Download: BidirectionalTCPChannel.zip (66 KB)

Usage

You can register this channel on the client side with

<channel type="DotNetRemotingCC.Channels.BidirectionalTCP.BidirTcpClientChannel, DotNetRemotingCC.Channels.BidirectionalTCP" />

and on the server side with

<channel type="DotNetRemotingCC.Channels.BidirectionalTCP.BidirTcpServerChannel, DotNetRemotingCC.Channels.BidirectionalTCP" port="9999" />

The URLs for your objects have to look like "bidirtcp://<IP_Address>:<port>/<ObjectURI>", for example "bidirTcp://127.0.0.1:9999/testobj.rem".

PLEASE NOTE: Hostnames are not yet supported in the URLs, please use IP addresses in this first preview release.

Known issues

• Needs support for automatic client reconnection include a server side timeout. Whenever the TCP connection drops due to network outages, the server should assign a grace period to the client. The server will in this case simply cache the event for some amount of time (like 10 seconds) and if the client reconnects during this time, no data is lost and no exception is thrown. 
• It only works with IP addresses in the configuration file. It should however also support 
  hostnames. 
• Performance: Too many new Threads. Will port to ThreadPool usage later.

Internals

As soon as a process is started, a GUID is assigned to it. Whenever a TCP connection is established, the two peers' GUIDS are exchanged. From this point on, the endpoint identifier is the GUID. When the client later passes an object to the server (callback interface or delegate), this GUID will be part of the dynamically generated ObjRef which contains the endpoint URLs for this object. If the server now calls this object, it will not see a URI like tcp://somehost:1234/URI/to/your/object (which would trigger the creation of a new connection from server to client) but instead at BidirTcpGuid://b28c92ed-d4b9-4fa6-a248-f5362caec380. The server will then check its connection table and retrieve the connection which corresponds to the GUID b28c92ed-d4b9-4fa6-a248-f5362caec380 to send the reply. The most important part is that the complete processing model for the underlying TCP connection has been changed: whereas the "normal" TcpChannel uses a request/response style connection oriented protocol, the BidirTcpChannel uses a message oriented protocol with correlation IDs to find matching request and response messages. That's somehow the only way things like this will work when you have only one connection available. However, this also means that this channel is not your average remoting channel and if it's the first one for you to look at, you might be a little shocked. But trust me, normal channels are way easier to understand ;)

Jabber Channel

This channel allows you to transfer .NET Remoting messages via Jabber.

Download Information

Download: JabberChannel.zip (21 KB)

SMTP Channel

This channel allows you to transfer .NET Remoting messages via SMTP and POP3.

Download Information

Download: SMTPChannel.zip (121 KB)

Documentation

This channel is from Ingo's book Advanced .NET Remoting. In chapter 10 he shows how to design and implement custom remoting channels.
He has open-sourced this channel with permission of Apress!

More documentation to follow. In the meantime you can refer to the Demos-subdirectory of this module which contains a sample for its use.