.NET Remoting Bidirectional Tcp Channel
by: Ingo Rammer
READ THIS FIRST: 03/09/2002 This channel is an early preview. It
contains highly un-optimized and un-scalable code to just prove my concept of a
bidirectional channel. I released it early to see if people are interested in a
channel like this and to see if others will join me in adding features.
Summary: Yes, you can download and develop with this channel now. No, you won't
be happy if you deploy it now.
Update 08/11/2002: This project is currently unsupported.
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 I don't have any ties at all!)
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
CVS Module Name: BidirectionalTcpChannel
CVS Web: http://soap.4s4c.com/cvsweb/cvsweb.cgi/BidirectionalTcpChannel/
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 ;)
FAQs
Q: Is this web service or GXA related?
A: No, not at all. It's completely non-GXA, non-WebService and will not
cooperate in any way with any WS-* specification. It's purely for applications
where you use .NET at the client and server side.
Q: Is this thing supported in any way?
A: No. But please send feedback to me at ingo@ingorammer.com
and I'll try to
work on your issues whenever I get the time to do so.
Q: Can I use it in commercial production applications?
A: Yes. But without any warranty or support. Please see the license which
is printed below and which can be found in the source code files.
Q: Is this channel from Microsoft?
A: No. It's been developed solely by an independent developer.
Q: Can we hire you as a consultant?
A: Glad you asked ;-)
I'm consultant, author, speaker, trainer and developer - mainly for distributed
.NET applications. I'm available for technical and architectural
consulting, on-site training and development throughout Europe.
If you currently look at developing a distributed .NET application, think about
designing/implementing an application framework, or just like what you see here
and think that you need a hardcore .NET person on your project, please don't
hesitate to contact me at ingo@ingorammer.com.
My services include: custom training, design, prototyping & architectural
review. I'm not normally available for long term project development. But if
you are working on something exceptionally interesting - who knows? ;-)
Q: What's the license of this component?
A: This component is covered by a liberal BSD/X11 style open source
license. It therefore allows you to modify, share, use (even in commercial
applications) this channel without any warranty and on your own risk. You
however must not remove the copyright statement.The complete license can be
found here.
Q: Can this channel be linked with GPL software?
A: Yes. The X11 license we use is compatible with the GPL.
Documentation
More documentation to follow. In the meantime, please refer to the Demos-subdirectory
of this module which contains a sample for its use.
| 
Architecture Briefings