Great news: 24 hours after the start I nearly finished the BidirectionalTcpChannel: SAOs, CAOs, sync calls, async calls, server to client events, and server to client callbacks all work over the same single TCP connection. I just need a little error handling when the connection is dropped (to remove it from my internal list of connections) and a little doc before releasing it.

Internally, it works like this:

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 ;)

Some issues which still need to be addressed:

• Client re-connection 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.
• Right now it only works with IP addresses in the configuration file. It should however also support hostnames.
• Performance: Too many new Threads. I guess I should look into using the ThreadPool more often ;-)