Cook Computing

System.Runtime.Remoting.Channels.Ipc

July 19, 2004 Written by Charles Cook

I recently came across this in the Visual Studio 2005 beta 1 documentation:

The System.Runtime.Remoting.Channels.Ipc namespace defines a communication channel for remoting that uses the Interprocess Communication system of the Windows operating system. Because it does not use network communication, the IPC channel is much faster than the HTTP and TCP channels, but it can only be used for communication between application domains on the same physical computer.

In the main application I'm working on at the moment we are using a custom channel based on named pipes to get good performance and I'd hoped that the IPC channel would at least equal this so that we could ditch our custom code. However I did some experimentation over the weekend and the IPC channel is currently about 50% slower than the TCP channel which in turn is about 50% slower than our named pipe channel. Of course, this is a beta and I was also running the code in Virtual PC which might have affected IPC more than the other channels, but I expected better performance than this.

The other Remoting disappointment in Whidbey is that I couldn't find anything to do with security. I'd been half expecting that security would be added to the remoting infrastructure in Whidbey but I guess that has been postponed until Indigo.

UPDATE: Remoting guru Ingo Rammer has pointed out that security has indeed been added to Remoting in Whidbey. You can specify authenticationMode (None, IdentifyCallers, ImpersonateCallers) and encryptionMode (None, Sign, EncryptAndSign) on the TcpServerChannel. The docs show how you can determine the identity of the caller:


// Identify the calling principal.
IIdentity remoteIdentity =
    System.Runtime.Remoting.Messaging.CallContext.GetData(
        "__remotePrincipal") as IIdentity;
if (remoteIdentity == null)
{
    message.Append(" by an unknown caller");
}
else
{
    message.AppendFormat(" by {0}", remoteIdentity.Name); 
}