Improved .NET Remoting in 2.0

Along with garbage collection, another element of the .NET wavethat I always thought wasn’t entirely thought out, and perhapsrushed to market, was .NET Remoting. There are just so many things about it that seemwrong (not the least that it has a relatively short lifespan beforeit is supercededby Indigo), and it seemed to be a downgrade from the so-called .dllhell of DCOM/COM+.Not only was it lacking many of the historic enterprise features ofCOM+ (even seemingly critical features like nativeauthentication and encryption), but the performance was deficientcompared to legacy communications technologies, and little quirkslike each channel being unidirectional just seemed absurd.

Thankfully, the performance issue has been improved dramaticallyfor same-machine communications with the addition of a newcommunications channel called IpcChannel. Using classic named-pipes, IpcChannel hasdemonstrated dramatic speed improvements even over the binaryTcpChannel. If you’ve properly configured remoting declaratively inyour config file, it’s a simple change to switch to IpcChannelwhere both ends of the conversation exist on the same logicalmachine. IpcChannel even lets you specify an Access Control List(ACL) to limit who can connect, which makes sense as authenticationand authorization is a native feature of named pipes.

Couple this with the new, easy to use authentication and encryption of .NET Remotingin 2.0 and it has turned into a pretty nice out-of-the-boxsolution.