Channel concepts

Channels are used to separate messages into different topics. They are the building block of creating a realtime application using the publish-subscribe pattern. Channels are also the unit of security and scalability. Clients should only ever be provided the capabilities for channels that they should have access to.

Messages contain the data that a client is communicating, such as the contents of an individual chat message, or an event that has occurred, such as updated financial information.

With basic pub-sub you create a channel, subscribe to it, and then publish messages to it. Most other Ably features utilize channels, or a group of channels, to provide additional functionality to your realtime applications.

To get started with implementing any feature, a client must first create or retrieve an instance of a channel. A channel is created, or an existing channel is retrieved from the Channels collection. You can only connect to one channel in a single operation.

Channels are identified by their unique name. The following restrictions apply to when naming a channel:

• Channel names are case sensitive
• They can’t start with [ or :
• They can’t be empty
• They can’t contain newline characters

While Ably doesn’t limit the length of channel names, we recommend you keep them under 2048 characters, since some older browsers have trouble with long URLs.

Use the get() method to create or retrieve a channel instance:

RealtimeREST
JavaScriptNode.jsJavaC# .NETRubyPythonObjective-CSwiftFlutterGo
Select...

const channel = realtime.channels.get('dad-aid-bee');

Copy
Copied!

Channels can be grouped together into a namespace. This enables you to apply operations to a namespace rather than each individual channel within it.

A namespace is the first part of a channel name up to the first colon (:). If a channel name does not contain a colon, the namespace is the entire channel name. For example, the following channels are all part of the ‘customer’ namespace:

• customer
• customer:tracking-id
• customer:order:update

Channel namespaces have the same restrictions as those listed for channels. Additionally they cannot contain the wildcard character *.

Use channel namespaces to apply operations to all channels within that group, such as capabilities, channel rules and integrations.

Clients subscribe to a channel to receive the messages published to it. Clients can subscribe to all messages, or only messages identified by specific names.

Publishing messages to a channel is how clients communicate with one another. Any subscribers will receive published messages as long as they are subscribed and have the subscribe capability for that channel.

Channel options are used to customize the functionality of channels. This includes enabling features such as encryption and deltas, or for a client to retrieve messages published prior to it attaching to a channel using rewind.

Metadata provides additional information about your apps and channels. It includes uses such as enabling clients to be aware of how many other clients are attached to a channel without the need to use presence, Examples of channel metadata available include the status and occupancy of specific channels.

Channel rules can be used to enforce settings for specific channels, or channel namespaces. They can be broadly categorized into three different types:

• For message storage
• For client security and identification
• To enable features for a channel or namespace

The channel rules related to message storage are:

Persist last message

if enabled, the very last message published on a channel will be stored for a year. This message is retrievable using rewind by attaching to the channel with rewind=1. If you send multiple messages in a single protocol message, for example calling publish() with an array of messages, you would receive all of them as one message. Be aware that presence messages are not stored and that messages stored in this manner are not accessible using history. Note that for each message stored using this rule, an additional message is deducted from your monthly allocation.

Persist all messages

if enabled, all messages published on a channel will be stored according to the storage rules for your account. This is 24 hours for free accounts and 72 hours for paid accounts. Messages stored in this manner are accessible using history. Note that for each message stored using this rule, an additional message is deducted from your monthly allocation.

The channel rules related to security and client identity are:

Identified

if enabled, clients will not be permitted to use (including to attach, publish, or subscribe) matching channels unless they are identified (they have an assigned client ID). Anonymous clients are not permitted to join these channels. Find out more about authenticated and identified clients.

TLS only

if enabled, only clients who have connected to Ably over TLS will be allowed to use matching channels. By default all of Ably’s client libraries use TLS when communicating with Ably over REST or when using our Realtime transports such as Websockets.

The channel rules related to enabling features are:

Push notifications enabled

If checked, publishing messages with a push payload in the extras field is permitted. This triggers the delivery of a Push Notification to devices registered for push on the channel.

Server-side batching

if enabled, messages are grouped into batches before being sent to subscribers. Server-side batching reduces the overall message count, lowers costs, and mitigates the risk of hitting rate limits during high-throughput scenarios.

To set a channel rule in the Ably dashboard:

1. Sign in to your Ably account.
2. Select an app.
3. Go to Settings tab.
4. Click Add new rule.
5. Select channel name or namespace to apply rules to.
6. Check required rules.

Channel history enables clients to retrieve messages that have been previously published on the channel. Messages can be retrieved from history for up to 72 hours in the past, depending on the persistence configured for the channel.

The presence feature enables clients to be aware of other clients that are ‘present’ on the channel. Client status is updated as they enter or leave the presence set. Clients can also provide an optional payload describing their status or attributes, and trigger an update event at any time.