I've been investigating partitioning a server application into separate processes so that verifiable .NET code can run in a separate environment where it can't be affected by unsafe C++, both managed and unmanaged. I was very surprised to see how poor the performance of Remoting via the TCP channel is compared to DCOM. Calling a simple method which takes a small string as its single parameter and returns another small string, TCP channel Remoting can only achieve about 1000 calls per second whereas DCOM was achieving about 9000 calls per second on the same machine.
The lower performance may be acceptable in the context I'm investigating but the lack of built-in authentication and authorization is more worrying. MSDN suggests:
If you have a choice between using the HttpChannel and the TcpChannel, it is recommended that you use the HttpChannel and host your remote objects in Internet Information Services (IIS), no matter what the user authentication and authorization models are. IIS hosting provides support for wire-level protection using Secure Sockets Layer (SSL) and authentication using Integrated Windows Authentication (formerly NTLM authentication) or Kerberos.
The TcpChannel, as an implementation of the Transmission Control Protocol (TCP), does not have default support for some of the robust authentication standards that the HTTP standard does. Within a secured environment (one that has wire-level protection such as IPSec), the high-speed TcpChannel can be used, but it is not recommended over the Internet or a nonsecure intranet.
Rearchitecting the server to run in IIS is not an option and the environment won't necessarily be secure, so using the TCP channel secure would require custom encryption sinks as described in Ingo Rammer's excellent Advanced .NET Remoting. However, do-it-yourself security is always a risky business and I'd much prefer it to be available as part of the framework. DCOM security can be a hassle but it does exist. Why wasn't similar functionality provided with Remoting?