The Super Channels
From RemObjects Wiki
This is an Article about RemObjects SDK
Feel free to add your notes to this topic below.
This article describes the Super Channels provided by the RemObjects SDK:
- the Super TCP Channel introduced in version 4.0
- the Super HTTP Channel introduced in version 5.0
They are the most advanced and flexible channels yet and are available for the following platforms:
Why Super Channels?
The question many of you probably have been asking yourself is: with so many channels to choose from already, why create more channels and what makes them different from the existing ones? That's a good question.
While the range of channels we shipped with the RemObjects SDK 3.0 and before offered a wide range of flexibility as far as the communication layer was concerned (TCP/HTTP, Email, Named Pipes, Windows Messages, etc), they had one limitation in common: they were basically one-way channels - the client could send requests to the server at will, but the server was limited to passively sending responses when asked.
This is more than sufficient for the vast majority of cases, especially the typical multi-tier database kind of applications that many RemObjects SDK users are building. However, there are certain scenarios where it is required for the server to actively contact the clients - for example to notify them of data changes, or to report back status or results of lengthy and possibly asynchronous processes.
These cases could be (and have been, in version 3.0) worked around, e.g. by using a polling mechanism where the client actively checks the server for new information at regular intervals. Such solutions, however, are less than ideal as they delay delivery of such server callbacks and also add unnecessary network traffic.
The Super Channels were designed from the ground up with one major goal in mind: to allow true two-way communication, enabling both the client and the server to actively send data on their own account, at any time.
How Do The Super Channels Work under the Hood?
In the existing channels (and we will be referring to the TCP channel for simplicity although the same concepts apply to all the other channels), communication works in such a way that the client dispatches a message, waits for a specific response and then stops worrying about the communication (regardless of whether the actual physical communication layer would remain active, for example with TCP Keep Alive).
Think of this like client and server using a standard walkie-talkie: when a request is sent off, the client presses his Send button, says "Server come in. Here's a request for you. Over ". The server then runs to process the request, presses the Send button and responds "Copy that. Here's the result of my processing. Over and Out. ", at which time the communication is over.
As with real walkie-talkies, communication has to be carefully planned and synchronized with the Over keyword. The server may only respond after the client has indicated he's finished, and must respond with the proper message. If the server were to start talking on his own (say to report back an event) while the client is in the middle of sending his request, the communication would be in deep trouble.
The Super Channels, instead, work like a regular two-way phone, allowing both parties to speak at the same time. If the server starts sending back an event while the client is in the middle of transmitting a new request, the client doesn't mind at all. It can listen while it talks, so it will accept the event and pass it back on, and just keep listening for the response to his original request. Similarly, the server can start accepting a new request that's coming in even while it's sending out events.
While all good analogies must come to an end, this should illustrate the core difference between the new Super Channels and the other channels. With the Super Channels, either side of the communication is ready to receive any kind of message, at any time - be it an expected response it is waiting for, or an unexpected out of band communication.
The way that this functionality is achieved differs between the two super channels, as is shown by the following two sections.
Keeping the Line Open (Super TCP Channel)
To enable this true two-way communication poses some challenges at the network level. Nowadays, most clients are no longer communicate directly, but have NATs or Firewalls between themselves and the internet. Therefore, servers usually cannot actively initiate a connection to the client on their own, but must rely on the client establishing the connection.
Just as with the existing TCP connection based channels, the Super TCP Channel maintains this concept, and connections will always be established from client to server, so they should work with the vast majority of all NAT and firewall scenarios, without any configuration necessary.
However, different from with the existing TCP connection based channels (including the legacy TCP and the HTTP channels), the Super TCP Channel relies on having a constant connection to the server at any time - if the connection is down, the server would have no way to contact the client to actively deliver events.
For this reason, the Super TCP Channel leverages a PING mechanism to make sure the connection stays alive. When idle, the client will send a small PING package at regular intervals, to check if the server is still available (i.e. the connection is still active). If the server does not respond, the client will assume the connection has been lost (which, due to the nature of TCP, sometimes can happen without the client or server getting the appropriate disconnect notification from the network stack), it will disconnect and try to re-establish a connection.
Similarly, the server will monitor traffic received from the client. If no messages (data or PINGs ) have been received for a certain period of time, it will consider the connection to be dropped, and go into offline mode for that particular client. In offline mode, any messages due to be sent to the client (whether events or responses to an active request) will be stored locally, and transmitted after the client has reconnected.
Keeping the Line Open (Super HTTP Channel)
The Super HTTP Channel works differently, as it has to work over HTTP, which doesn't allow for two way traffic in the way asynchronous code requires. Instead, it uses two connections: one for sending requests and one that waits for responses and events to be available. This makes it possible to send multiple requests at once, making it a truly asynchronous channel. As this runs over HTTP, it's possible to use it through a firewall.
Using the Super Channels
How can you make use of these new features in your own applications? The good news is that all of this functionality will work seamlessly behind the scenes when using the Super Channels.
If your current application uses HTTP or legacy TCP to communicate between client and server (which means it might be polling for events; background worker threads to simulate asynchronous calls, etc), all you need to do is replace the server channel type (or, on the server, add the Super TCP Channel or Super HTTP Channel as an additional supported server type), and all the benefits of the Super Channel automatically come active.
Enabling Your Application for Super Channel Specifics
While the Super Channels will "just work" as soon as you drop them and hook them up, it does provide certain settings and events that you might want to use.
For example, the client channels provide OnConnect/OnDisconnect events to notify your application whenever a connection has been established or dropped. Depending on how essential a live connection is for your end-user, you might be interested in hooking these events up to show the online/offline status as part of the user interface - e.g. via the status bar or by disabling certain UI elements when the connection is offline.
Another feature of the Super Channels that you can use within your code is that they allow sending several requests at the same time, from separate threads. So if you previously juggled separate instances of your channel to allow several threads to communicate with the server at the same time, these threads can now share a single Super Channel instance.
Note that the Super Channels maintain their own copy of the ClientID used to uniquely identify the client for sessions, as every client connection will of course be associated with one particular client, and the ClientID will be needed for event delivery.
In most normal scenarios, this ClientID will automatically be synced with the ClientID stored in the Message you are using. However, if you are manually modifying or setting ClientIDs in your application (e.g. because you persist the ClientID between restarts of your application), it is recommended that you manually initialize both the ID on the message and on the Super Channel.
When to Use the Super TCP Channel
The Super TCP Channel is the ideal candidate in the following situations:
- Virtually whenever you do not have a good reason to use another channel - the Super TCP Channel makes a good default channel to use most of the time.
- You need timely delivery of events back from server to client.
- You need events to be sent between Delphi servers and .NET clients, or vice versa - at this time the Super TCP Channel is the only channel that supports cross-platform events.
- Keeping a constant open connection and a constant trickle of (very low) network traffic is not a problem.
When to use the Super HTTP Channel
- When you need the features of the Super TCP Channel, but need to be able to work from behind a restrictive firewall or proxy.
- You need timely delivery of events back from server to client.
When not to use the Super Channels
You should avoid using the Super Channels in these situations:
- If you do not need events and your current TCP or HTTP based application works fine - no need to change a running system, if you don't need the new features.
- If you don't need events and traffic minimization is important - while more flexible, the network overhead of the Super Channels is slightly higher than the other channels; if you don't need the extra features, staying with plain TCP/HTTP will save a few bytes per message.
- If a constant connection or regular traffic are not acceptable, e.g. on a dial-in network or on mobile applications using GSM or GPRS connections that incur per-minute or per-kilobyte charges.
Note that thanks to the RemObjects SDK's Smart Service™ architecture, you can of course use a combination of channels in your application - e.g. making use of the Super Channels for normal clients and falling back to standard HTTP for clients running on a GSM/GPRS-connected device.
Summary
We hope this article has given you a brief but helpful introduction to the Super Channels. For more information, please refer to the RemObjects SDK online help and the samples that ship with the SDK, in particular the Super TCP Channel Chat sample.
Product: RemObjects SDK
Available Editions: RemObjects SDK for .NET, Delphi, Xcode, Java and JavaScript
Glossary — Architecture — Articles — Features — Library — Samples
