Choosing the channel type

Channel components are the heart of the Remoting SDK. They connect your client applications and your server applications by sending messages back and forth, for example to submit a request, return a response, fire a callback event, etc. No matter what type of application you are building with Remoting SDK, channels will be an integral part of it.
Note: For historic reasons, the Remoting SDK for Delphi class library uses the terminology Channel for client channels and Server for server channels, while more modern editions properly refer to client channel and server channel. Besides these naming differences, the same concepts apply for either platform.
To accommodate your needs, you have to make choices on different levels, starting with the base protocol and going down to the concrete channel implementation classes and components.

Choosing the Base Protocol

There are several options for the underlying communication level protocol that will be used to transmit your messages. The most widely used protocols are TCP and HTTP.

TCP Channels

TCP channels use raw TCP sockets, one socket per client, to transmit data between the client and the server. The TCP protocol contains only a minimal amount of traffic overhead inside, but it is not proxy-friendly. It also does not allow third party clients to connect to RO servers easily. Use this channel when minimizing traffic is a priority.

HTTP Channels

HTTP channels use HTTP to establish communication between the client and the server. They have more traffic overhead for HTTP-specific needs, but they can successfully pass proxies and allow to build a server usable with third party clients and to build Smart Services (which are accessible with different messaging protocols simultaneously). Nowadays, the HTTP channel is the most common choice for communication.

Plain Channels vs. Super Channels

Both TCP and HTTP channels have plain and super versions. Plain versions have a relatively simple logic: The connection is established, the request is sent, and when the answer is received, the connection closes. Plain channels always use one connection (socket) per client.
Super channels keep the connection constantly open and reestablish it when it is closed for any reason. This approach has the following advantages:

Instant server to client communication. In case Callback events are used, the event package is delivered immediately, while simple channels need to query the server periodically.
Asynchronous remote invocation. You can send remote requests without the need to wait for the preceding request to complete.

But there are also drawbacks:

The permanently open connection may consume valuable resources and provide an extra load to the network infrastructure.
Load balancing usage is limited. A SuperTCP client channel must be connected to the same server for the entire client session duration, and in case of a connection drop, reconnecting to a different server will lead to errors. A SuperHTTP channel uses two underlying connections, both must be connected to the same server for the entire client session duration.

So, Super Channels are a good choice if you need 2-way communication and asynchronous request invocation.

Less Common Protocols

There is a number of less common communication options primarily supported in Remoting SDK for Delphi.

Local Channel - Allows to communicate within the same application. It is useful to easily invoke service methods from the server application or to prepare a scalable system to be separated to client and server applications later.
Named Pipe Channel - Establishes communication over the LAN without using any TCP/IP communication. Microsoft Windows only.

Supported by Remoting SDK for Delphi only:

UDP channel, including the broadcast version.
DLL Channel - Allows to build a local application that talks to services located in a specially designed local DLL file.
Email Channel - The client uses POP3/SMTP communication to talk to the server.
WinMessage Channel - Used for interprocess communication on the same computer, WinAPI windows messages are used.

The Specifics of Different Implementations

Delphi and .NET editions of Remoting SDK allow to use different channel implementations for the same protocol. Novice users sometimes feel lost in this variety.

Note: regardless of the implementation or platform, client and server channels using the same protocol are wire compatible, so from this point of view it doesn't matter which particular implementation is used. Refer to the Channel Compatibility table for the complete list of compatible channels per protocol.

However, you may find the following information about different channel implementations useful:

There are 3 versions of primary channels in Remoting SDK for Delphi: Indy based, Synapse based and WinInet based.
Indy based channels provide better cross-platform portability of the code while Synapse looks more simple and straightforward. Both libraries are still under development and not guaranteed to be 100% error free.
WinInet is Windows only, but is stable, feature rich and well integrated with Windows internet settings.
Remoting SDK for .NET allows to choose between Internet Pack for .NET based channels and system based ones. System based channels are more feature-rich but more complex to fine-tune. They also require elevation when used in UAC enabled environments.
Cocoa, Java and JavaScript editions use native APIs only, so they provide no alternative channel versions.