Factoids about HTTP and TCP remoting channels

Here are some factoids about the HTTP and TCP channels in .NET remoting.

Remoting itself works equally well over HTTP or TCP. The core functionality is the same either way.

However, there are numerous differences. Here are some of them:

• TCP requires that you create your own server-side host app
• HTTP works with either IIS as a host, or your custom host
• TCP is slightly faster than HTTP
• HTTP defaults to using the slower Soap formatter
• TCP defaults to using the faster Binary formatter
• HTTP supports the faster Binary formatter - you just need to select it
• Both HTTP and TCP can run over virtually any unused port on the server
• You can debug HTTP by navigating to it in a browser

Then there's the difference between using IIS as a host, or writing your own custom app as a host:

• If you use IIS as a host, you must use the HTTP channel
• If you use a custom host you can use both HTTP and TCP channels
• If you use IIS as a host, IIS controls the port for remoting
• If you use a custom host it controls the port for remoting
• If you use IIS as a host, it defaults to port 80
• If you use IIS as a host, you get security benefits (SSL, etc)
• If you use IIS as a host, you get management benefits
• If you use a custom host you write all that stuff yourself

(Updated 3/5/2003)