Choosing a Channel

This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).

The .NET Framework remoting infrastructure provides the following channel implementations:

IpcChannel

The IpcChannel class uses named pipes to provide high-speed interprocess communication for multiple process applications on the same computer. An IpcChannel :

  • Communicates between sender and receiver by using named pipes.

  • Supports encoding payloads in binary format and the industry standard SOAP serialization format.

  • Generates and consumes ChannelDataStore for object references.

  • Supports impersonation and delegation.

  • Supports access control lists (ACL) on the named pipe for advanced access control.

Use an IpcChannel when an application must communicate with another application that runs in a different process on the same computer. Because the IpcChannel uses named pipes, applications can generally obtain the highest communication performance and use impersonation and delegation to control access to the remote object. This functionality is especially useful between the second and third tiers of a three-tier application that must perform well under load.

TcpChannel

The TcpChannel class uses a binary formatter to serialize all messages to a binary stream and to transport the stream to the target Uniform Resource Identifier (URI) by using the TCP protocol. A TcpChannel performs the following functions.

  • Communicates between sender and receiver by using TCP sockets.

  • Supports encoding payloads in binary format and the industry standard SOAP serialization format.

  • Generates and consumes ChannelDataStore for object references.

  • Supports impersonation and delegation.

  • Supports SSPI encryption.

A TcpChannel opens and caches as many connections as there are threads making requests to another server at that moment. Socket connections are closed on the client after 15-20 seconds of inactivity.

If you are building a number of applications that use .NET Framework remoting, it can be easy to mistakenly use a HttpChannel to connect to a server application domain that listens with a TcpChannel. If you make this connection, the client receives the following exception: "The underlying connection was closed: An unexpected error occurred on a receive." If you have a client that receives this exception, you should check the client and the server for mismatched channels.

HttpChannel

The HttpChannel class transports messages to and from remote objects by using the SOAP protocol. All messages are passed through a SoapFormatter, where the message is changed into XML and serialized and the required SOAP headers are added to the stream. If the binary formatter is also specified, a binary data stream is created. The data stream is then transported to the target URI by using the HTTP protocol. A HttpChannel is compliant with SOAP 1.1 and performs the following functions:

  • Communicates between sender and receiver by using the HTTP protocol as a transport.

  • Supports encoding payloads in SOAP, which is an XML encoding standard, as well as a binary format.

  • Sets the receiver to receive HTTP requests and send HTTP responses in ASP.NET and on a TCP socket.

  • Generates and consumes ChannelDataStore for object references.

  • Supports impersonation and delegation.

  • Supports SSPI encryption.

Note

To use a HttpChannel on the client with Microsoft Internet Explorer, you cannot set the automatic configuration of proxy settings in Internet Explorer. Instead, you must explicitly set the proxy settings in Internet Explorer.

A HttpChannel opens only a specified number of connections at one time to a given server. The default is two, but you can use the clientConnectionLimit attribute in an application configuration file to change the default.

If you are building a number of applications that use .NET Framework remoting, it can be easy to mistakenly use a HttpChannel to connect to a server application domain that listens with a TcpChannel. If you do, the client receives the following exception: "The underlying connection was closed: An unexpected error occurred on a receive." If you have a client that receives this exception, you should check the client and the server for mismatched channels.

See Also

Reference

HttpChannel
TcpChannel
IpcChannel

Concepts

Channels