First alpha version available: BidirectionalTcpChannel.

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.

Disclaimer: Use at your own risk. If you develop a stock brokering application based on this channel and a sudden interuption in service leads to a NASDAQ crash, it's you who's going to talk to the SEC. Keep out of the reach of children. Keep away from fire. May detonate if heated or mixed with water. Store in a cool and dry place. Check the license.

Second disclaimer: Performance will get better with the next release. I'll switch from individual threads to ThreadPool and will change the ITransportHeader serialization format.

John Bristowe, who just started a weblog as well [rss subscribed], stumbled upon the WSDK which includes WS-Security, WS-Routing, WS-Attachments, and DIME... oh my! Way cool.

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

I'm currently working on something I call the BidirectionalTcpChannel for .NET Remoting which will be put in our Open Source Remoting Projects.

Rationale: The classic TCPChannel in Remoting allows the server to raise events (or employ callback interfaces) to notify its subscribed clients. The problem however is that the server will open a new tcp connection back to the client, which implies that events are simply not possible via NATs or firewalls. The BidirectionalTcpChannel will get rid of this limitation by switching from the classic request/response model of the TcpChannel to a message oriented model - thereby enabling reuse of the existing connection (the one which has been initiated by the client) to pass callbacks and events back to the client.

Status: I started working on this channel yesterday in the evening and currently have a basic message oriented tcp channel (still one-way!) using correlation IDs to map synchronous message calls onto the underlying async model.

I'll keep you updated ...

Some time ago, I realized that the most interesting things regarding .NET Remoting or W/S tend to happen whenever I'm away from the Net for some days.

This week, the highly anticipated SSPI channel + docs have been released. The necessary Things To Keep Remoting Secure are therefore:

• Microsoft.Samples.Security.SSPI
• Microsoft.Samples.Runtime.Remoting.Security
• SecureRemoting.ZIP (for SSL style transport encryption)

Thank's to Drew for noticing and posting the links!

As I'm currently setting up my new computer [1], I once again remembered this nice little trick for searching the Microsoft knowledge base. Maybe it's an old one for you but I thought I'd share it nevertheless:

Download TweakUI from the PowerToys for Windows XP website. Start it and go to Internet Explorer -> Search -> Create. Enter "kb" (or whatever you like) as a prefix and enter this URL (on a single line):

http://search.microsoft.com/default.asp?so=RECCNT&siteid=us%2Fdev&p=1
&nq=NEW&qu=%s&IntlSearch=&boolean=ALL&ig=01&i=00&i=01&i=02&i=03
&i=04&i=05&i=06&i=07&i=08&i=09&i=10&i=11&i=12&i=13&i=14&i=15&i=16
&i=17&i=18&i=19&i=20&i=21&i=22&i=23&i=24&i=25&i=26&i=27&i=28&i=29
&i=30&i=31&i=32&i=33&i=34&i=35&i=36&i=37&i=38&i=39&i=40&i=41&ig=02
&i=42&i=43&i=44&i=45&i=46&i=47&i=48&i=49&i=50&i=51&i=52&i=53&i=54
&i=55&i=56&i=57&i=58&i=59&i=60&i=61&i=62&i=63&ig=03&ig=04&ig=05
&ig=06&ig=07&ig=08&i=99

You will then be able to simply enter "kb something" in IE's address line to search for "something" at microsoft.com (including the knowledge base). Of course you can add more prefixes and URLs to search at your favorite search engine as well - just take the URL and put %s in the place where your search string should appear.

[1] Sony simply rocks the notebook world. Don't know how I could ever work with something smaller than 1600x1200 ...

Clemens is nearly done with his book: I just have to submit another four pages that require some more testing of a sample, since it involves some creative abuse of MS DTC.

Congrats! Just be sure to tell us as soon as your book is available - I'm really looking forward to playing with this DTC sample.

If you want to know more about the book's content and focus, please check this page or just drop me an email at rammer@sycom.at. Just to give you some hints: this book contains for example the world's first complete remoting channel developed in VB .NET.

[And of course a whole lot of other useful information about .NET Remoting ...]

Peter Drayton: I ran into some issues doing Remoting under Rotor, probably the same ones k10n did. A kindly soul at Microsoft took pity on me ;-) and helped me get them fixed (thanks guys!). If anyone wants to try out these demos using Rotor rather than the desktop product, replace sscliclrsrcvmecall.cpp with this file and rebuild.