Comparison of the Remoting SDK Channels

This article provides a summary of each of the channels provided by the Remoting SDK:

Frequently used channels

  • Legacy TCP Channel: lightweight communication over raw TCP.
  • Email Channel (Delphi): asynchronous communication over existing email infrastructure.
  • Local Channel: direct communication within the same application.
  • DLL Channel (Delphi): implements server logic inside a DLL and accesses it using the standard Remoting SDK calling mechanisms.

Rarely used channels

HTTP Channel

The most commonly used channels are probably those based on the Hypertext Transfer Protocol. The HTTP protocol, which forms the basis for the world wide web, is one of the most used protocols on the Internet, and provides a variety of benefits when used for communication within the Remoting SDK:

  • Because of the widespread use of HTTP, the protocol can be easily used, even in restrictive network environments, where firewalls or proxy servers are used to separate the client from the Internet. If end-users have access to the Internet via web browser, chances are high that HTTP based channels will work out-of-the-box, as well.
  • Server addresses are identified by standard URLs, making it easy and intuitive for the end user to handle addressing.
  • If desired, HTTP channels can provide human-readable information about the server and the published services, when accessed from a standard web browser.

In summary, HTTP is the best protocol to use if you have little control over the network infrastructure at the deployment site, and want your clients to easily work on a wide variety of networks.

Several implementations of the HTTP client and server channels are provided in both editions (Delphi and .NET), and the decision over which ones to use is mostly a matter of preference and taste. All of the HTTP clients are compatible with any of the HTTP servers, and vice versa.

It is worth noting, that the WinINET based client channels for both Delphi and .NET will make use of networking options set up for Internet Explorer, including proxy settings and automatic dial-up rules, while the Indy and Internet Pack channels use their own HTTP implementation on top of raw TCP.

Client Channel Components:

Server Channel Components:

Note: The HttpSysServerChannel uses Microsoft's HTTP kernel shared with IIS, which allows standalone servers to share a port with the IIS web server. Also this channel requires elevation when running in UAC-enabled environment (Vista, Windows 7, ...).

Super TCP Channel

The Super TCP Channel components provide a sophisticated and flexible communication channel that uses persistent connections to enable true asynchronous calls and server callbacks.

Leveraging a custom-defined protocol on top of a raw TCP connection, the channel allows for advanced features lacking in the more traditional channel types:

  • Keep-Alive connections, with flexible ping/pong system to discover broken connections (for example due to network outages) together with seamless recovery.
  • Out of band server/client communications enable the server to actively send events or asynchronous responses back to the client without the need for polling - reducing network traffic and efficiency for these callbacks.
  • Allows multiple requests to be sent at once over a single channel.

Use this channel for scenarios where extensive use is made of events and server callbacks, and wherever firewalls and proxy servers do not require the use of HTTP based channels.

Client Channel Components:

Server Channel Components:

Super HTTP Channel

This channel offers the same two-way communication features as the super tcp channel, but it works through HTTP, thus allowing it to pass through strict proxies and firewalls. It has slightly more overhead than the super tcp channel though, as it uses two connections to the server.

Client Channel Components:

Server Channel Components:

Legacy TCP Channel

TCP, the Transmission Control Protocol, is one of the two basic low-level protocols that form the basis of the internet with its TCP/IP network stack, and provides a stream based connection between a client and a server host. While TCP also provides the foundation for most more complex protocols such as HTTP, POP3 etc, the Legacy TCP Channel uses a lightweight protocol over raw TCP, introducing basically zero traffic overhead on top of the transmitted message data.

The Legacy TCP Channel is the perfect choice when traffic minimization is a must and firewalls are not an issue. The Legacy TCP Channel will provide the best possible performance for method calls, in this scenario.

Client Channel Components:

Server Channel Components:

Email Channel (Delphi)

The Email channel implements asynchronous communication by using standard email and existing POP3 and SMTP servers to send requests to a server and retrieve responses.

The client channel is configured with the server's email address and uses that address to send requests off to the server for processing. The server will retrieve these emails from a POP3 mailbox, process the requests and eventually send the results back to the client, again via email. The client channel can poll its own POP3 mailbox to obtain the response.

This channel is ideal for running requests with long execution times that could potentially outlive a single client session. Since requests and responses are persisted in POP3 email boxes, a client application could send a request, exit, and then retrieve the response hours or even days later. Similarly, requests can be sent to a server that might not currently be running - when the server starts up it will catch up and process emails that are waiting in its email inbox.

Client Channel Components:

Server Channel Components:

Local Channel

The Local Channel allows Remoting SDK based communication within a single .NET or Delphi application; enabling you to easily reuse your client and server in a monolithic application, or to build single tier applications, that can later be scaled out easily by changing channel types.

While at first sight it might seem useless to partition application logic into client and server and then proceed to embed both parts in the same executable, these channels are helpful for two scenarios, especially when combined with the Data Abstract database multi-tier architecture:

  • to implement a single-tier application with scalability in mind, so that it can easily be scaled up to a true multi-tier solution, should the need arise.
  • to reuse an existing multi-tier application and deploy it in a single-tier environment - for example to sell a single-user edition of the product, or to provide a desktop version of a client/server database front end.

In both cases, and similar scenarios, the local channel makes it easy to combine the client and server tier in a single application, with negligible communication overhead between the tiers, but maintaining the logical multi-tier separation.

Client Channel Components:

Server Channel Components:

DLL Channel (Delphi)

The DLL Channel allows you to implement server logic inside a DLL and access it using the standard Remoting SDK calling mechanisms. The channel will automatically load the DLL into the client process and expose the server methods in the same fashion as a remote server would.

See the Local Channel section above for why you might want to use this channel.

Client Channel Components:

Server Channel Components:

UDP and Broadcast Channels (Delphi)

Next to TCP, UDP is the second base transfer protocol of the internet's TCP/IP network infrastructure. In contrast to TCP, UDP does not provide the concept of a stream based connection between client and server, but instead sends individual data packets - so called datagrams over the network.

UDP also provides no error correction or guaranteed delivery, so packets sent via UDP might get lost and not arrive at the target destination, or get corrupted and simply discarded. Also, UDP doesn't support large packages, which get truncated. On the upside, the UDP protocol is very fast and efficient compared to TCP.

You should consider using the UDP based channel if you need to send small data packets at high frequency and very efficiently, and you don't need to rely on network error correction and package recovery features provided by TCP. Most likely this will be in LAN scenarios, where network infrastructure is dependable and chances of packet loss are minimal.

The UDP and Broadcast Channels is a variation of the UDP channel, that allows you to send requests to all available servers listening on the local network using UDP broadcast. This is useful in notification scenarios, or for discovering available servers.

You will usually use both of these channels in asynchronous mode; For broadcast scenarios, your servers will either call ROSendNoResponse to prevent any response form being sent (so that a large number of recipients can quietly swallow a notification message), or your client will be prepared to receive multiple responses.

Client Channel Components:

Server Channel Components:

Named Pipe Channel

This channel provides communication between a client and server using Window's Named Pipes feature. Named pipe is recommended for communications between processes on the same computer, especially when run via separate users. This could be useful, for example for service control.

Please refer to the Platform SDK or MSDN documentation on Named Pipes for more details.

Tip: one important thing to bear in mind: Windows has a set limit for the number of clients connected to a named pipe at once - 5 for Home, 10 for Pro. TCP/IP is a better alternative if you want to run a network server.

Client Channel Components:

Server Channel Components:

WinMessage Channel (Delphi)

This channel provides communication by sending Windows Messages between the client and the server application.

While providing an easy way for Inter Process Communication on a single computer, Windows Messages have several limitations - they cannot be used to communicate servers running as Windows Services, and they rely on a Windows Message Loop being active in both client and server. Please refer to the Platform SDK or MSDN for more details on these concepts.

Client Channel Components:

Server Channel Components:

Summary

This article has compared the various channels and which to use best for your scenario. If you have any questions or problems using them, please contact support.