Presence

Presence enables clients to be aware of other clients that are currently “present” on a channel. Each member present on a channel has a unique self-assigned client identifier and system-assigned connection identifier, along with an optional payload that can be used to describe the member’s status or attributes. Presence enables you to quickly build apps such as chat rooms and multiplayer games by automatically keeping track of who is present in real time across any device.

Other devices and services can subscribe to presence events in real time using the realtime interface or with integrations. You can also request a list of clients or devices on a channel at a particular point in time with the REST interface.

Whenever a member enters or leaves a channel, or updates their member data, a presence event is emitted to all presence subscribers on that channel.

The following presence events are emitted:

Enter

A new member has entered the channel

Leave

A member who was present has now left the channel. This may be a result of an explicit request to leave or implicitly when detaching from the channel. Alternatively, if a member’s connection is abruptly disconnected and they do not resume their connection within a minute, Ably treats this as a leave event as the client is no longer present

Update

An already present member has updated their member data. Being notified of member data updates can be very useful, for example, it can be used to update the status of a user when they are typing a message

Present

When subscribing to presence events on a channel that already has members present, this event is emitted for every member already present on the channel before the subscribe listener was registered

In addition to the client_id for members on a channel, it is also possible to include data when entering a channel. Clients can update their data at any point which will be broadcasted to all presence subscribers as an :update event.

The following is an example of subscribing to enter and leave events, then entering the presence set and updating a client’s member data:

Realtime
JavaScriptNode.jsJavaC# .NETRubyObjective-CSwiftGoFlutter
realtime_ruby

# Subscribe to presence enter events
channel.presence.subscribe(:enter) do |member|
  puts member.data # => not moving
end


# Subscribe to presence update events
channel.presence.subscribe(:update) do |member|
  puts member.data # => travelling North
end


# Enter this client with data and update once entered
channel.presence.enter(data: 'not moving') do
  channel.presence.update(data: 'travelling North')
end

Copy
Copied!

An Ably client instance might, if on an application server for example, publish messages and be present on channels on behalf of multiple distinct client IDs. The channel’s Presence object therefore also supports methods that enable presence messages to be emitted for a client_id specified at the time of the call, rather than implicitly based on the client_id specified when the SDK is instantiated or authenticated.

Each unique client_id may only be present once when entering on behalf of another client as the unique identifier for each member in a presence set is the combined client_id and shared connection_id>.

A single client_id may be present multiple times on the same channel via different client connections. Ably considers these as different members of the presence set for the channel, however they will be differentiated by their unique connectionId. For example, if a client with ID “Sarah” is connected to a chat channel on both a desktop and a mobile device simultaneously, “Sarah” will be present twice in the presence member set with the same client ID, yet will have two unique connection IDs. A member of the presence set is therefore unique by the combination of the clientId and connectionId strings.

In order to be able to publish presence changes for arbitrary client IDs, the SDK must have been instantiated either with an API key, or with a token bound to a wildcard client ID.

REST
JavaScriptNode.jsRubyJavaC# .NETObjective-CSwiftGoFlutter
rest_ruby

rest = Ably::Rest.new(key: '<loading API key, please wait>')
# request a wildcard token
rest.auth.requestToken(clientId: '*') do |token|
  realtime = Ably::Realtime.new(token: token)
  channel = realtime.channels.get('realtime-chat')


  channel.presence.subscribe(:enter) do |member|
    puts "#{member.client_id} entered realtime-chat"
  end


  channel.presence.enter_client 'Bob' # => Bob entered realtime-chat
  channel.presence.enter_client 'Mary' # => Mary entered realtime-chat
end

API Key:
Demo Only
Copy
Copied!

Subscribe to a channel’s presence set in order to receive presence events, by registering a listener. Presence events are emitted whenever a member enters or leaves the presence set, or updates their member data.

Subscribing is an operation available to the realtime interface of an Ably SDK and uses the subscribe() method on the Presence object of a channel.

The following is an example of subscribing to presence events and entering the presence set:

Realtime
JavaScriptNode.jsRubyJavaC# .NETObjective-CSwiftGoFlutter
realtime_ruby

realtime = Ably::Realtime.new(key: '<loading API key, please wait>', client_id: 'bob')
channel = realtime.channels.get('oat-boy-fun')
channel.presence.subscribe(:enter) do |member|
  puts "Member #{member.client_id} entered"
end
channel.presence.enter

API Key:
Demo Only
Copy
Copied!

The number of clients that can be simultaneously present on a channel is limited. This ensures the rate of presence messages remains supportable, as it is common for all members on a channel to change state at a similar time.

As an example, consider 200 clients subscribed to presence events on a channel and all of them join and leave the presence set within a few minutes. This would result in the following messages:

• 200 presence messages published for the enter event.
• 200 × 200 (40,000) messages subscribed to for the enter events.
• 200 presence messages published for the leave event.
• 200 × 200 (40,000) presence messages subscribed to for the leave events.

This highlights the potential for 80,400 messages to be sent in a very short space of time on a single channel.

If your application needs to have all clients subscribed to presence messages then enabling server-side batching can reduce the number of events received by clients. If your application doesn’t need to have all clients subscribed then you can set some of them to be present without subscribing.

Enabling server-side batching for a channel means that Ably will group any messages that are published within a set period of time into batches. These batches are then delivered to subscribers as a single message.

The interval over which this batching occurs is configurable. This is to ensure the trade-off between cost efficiency and user experience is appropriate, as a higher interval will increase the latency between message deliveries. This is usually less impactful to user experience for presence events than for regular messages.

Using server-side batching for presence events can reduce message costs when the membership of a channel is constantly changing. It also allows for a higher number of presence members per channel to be supported. By default, the number of presence members per channel is limited to 200. With server-side batching enabled, this increases up to 20,000 clients depending on your package type.

Messages are streamed to clients as soon as they attach to a channel, as long as they have the subscribe capability.

Efficient use of capabilities can prevent clients from receiving presence events while still allowing them to enter the presence set. This is a common scenario where only a server is required to monitor the presence set. This saves clients from subscribing to a potentially high volume of unnecessary messages.

One example of achieving this would be to use one channel for generic communications and another for the presence set. The following capabilities demonstrate this for clients and for servers:

For clients:

{
  "chatPresence": ["presence"],
  "chat": ["publish", "history", "subscribe"],
}

Copy
Copied!

For servers:

{
  "chatPresence": ["presence", "subscribe"],
  "chat": ["publish", "history", "subscribe"],
}

Copy
Copied!

Alternatively, channel mode flags can be used to enable clients to be present on a channel without subscribing to presence events. This also enables clients to still subscribe to regular messages on the channel.

The membership of the presence set can be retrieved by calling the get() method on the Presence object of a channel. This returns an array of all members currently present on the channel and is available using the REST and realtime interfaces of an Ably SDK.

An Ably client connected using the realtime interface of an SDK is responsible for keeping track of the presence set from the time that the channel is attached. An up to date presence set is pushed to the client following a channel attachment, and the presence set is updated on each subsequent presence event. This means that get() returns the already known presence set retained in memory and does not trigger a new request to the Ably service.

The REST interface of an Ably SDK queries the REST API directly. No presence state is cached in the SDK itself.

The following is an example of retrieving the presence set for a channel:

RealtimeREST
JavaScriptNode.jsRubyJavaC# .NETObjective-CSwiftGoFlutter
realtime_ruby

channel.presence.get do |members|
  puts "There are #{members.size} members on this channel"
  puts "The first member has client ID: #{members.first.client_id}"
end

Copy
Copied!

A common requirement of the presence set is to keep an updated list of members that are currently present on a channel in your user interface.

Many developers try to build the initial list using the get() method and then mutate that list whenever a new presence event arrives. Ably advises against this approach, because it’s easy to quickly go wrong and end up with a list that’s out of sync with the real presence set.

One common error is to fail to take into account that a single clientId may be present multiple times on the same channel via different connections. As far as Ably is concerned, these are different members of the presence set as they have different connectionIds. For example, if a client with the ID “Sarah” is connected to a channel on both a desktop and a mobile device simultaneously, or via multiple tabs in a browser, “Sarah” will be present twice in the presence set with the same clientID. If “Sarah” leaves the channel on her mobile, your app sees the leave event and incorrectly removes her entry from the list.

Ably recommends that you instead just get() the presence set afresh from the Ably SDK whenever you see a presence event and use it to rebuild the list of members in your user interface. The get() operation is free and a local call to the SDK and provides you the presence set that the client has already synced with the server. The server keeps the presence set up to date and there is not cost to using this approach.

The following is an example of calling the get() method on presence messages:

Realtime
JavaScriptGoJava
Select...

await channel.presence.subscribe(async (presenceMessage) => {
  // Ignore the presence message, just rebuild your state from the get() method
  // (including uniquifying by clientId if you only want one entry per clientId)
  const presenceSet = await channel.presence.get();


  if (presenceSet.length > 0) {
    console.log('There are ' + presenceSet.length + ' members on this channel');
  } else {
    console.log('There are no members on this channel');
  }
});

Copy
Copied!

It is possible to retrieve the presence state of multiple channels in a single request. The presence state contains details about the clients in the presence set, such as their clientId, member data and presence action.

A batch request has a single set of request details containing the request body, parameters and headers. These are converted into an array of requests to the underlying API. Each individual request to the underlying API is performed in parallel and may succeed or fail independently.

The following is an example of a batch presence request using the request() method to query the batch REST API

REST
JavaScriptPHPJava
Select...

const ablyRest = new Ably.Rest({ key: '<loading API key, please wait>' })
const content = { 'channel': 'channel1,channel2' }
const presenceSets = await ablyRest.request('GET', '/presence', null, content, null);
console.log('Success! status code was ' + presenceSets.statusCode);

API Key:
Demo Only
Copy
Copied!

A batch presence request contains a comma separated list of channel names with no spaces.

The following is an example of a batch presence request using the request() method to query the batch REST API

REST
JavaScriptPHPJava
Select...

var ablyRest = new Ably.Rest({ key: '<loading API key, please wait>' })
const content = { 'channel': 'quickstart,channel2' }
const presenceSets = await rest.request('GET', '/presence', content, null, null);
console.log('Success! status code was ' + presenceSets.statusCode);

API Key:
Demo Only
Copy
Copied!

The following is an example curl request, querying the REST API directly:

curl -X GET https://rest.ably.io/presence?channel=quickstart,channel2 \
    -u "<loading API key, please wait>"

API Key:
Demo Only
Copy
Copied!

Once all requests have been completed in a batch request, a batch response is returned with three possible outcomes:

Success

If all of the individual requests were successful then an array containing the response of each query is returned in request order.

Failure

If the batch request itself failed before the individual requests were made, then an error response is returned with a status code and error response body. Examples of why the batch request can fail include an authorization failure or an invalid request.

Partial success

If one or more of the individual requests failed the response body contains an error object with the error code 40020 and a status code of 400. The error body contains a batchResponse array of each individual response in request order. The batchResponse can be inspected if there is a need to know the details of each outcome. If you only need to know whether or not the batch request was completely successful then the status code is sufficient.

The examples for each possible outcome will use the following request data:

{
  channel: 'channel0,channel1,channel2'
}

Copy
Copied!

The following is an example of a successful batch presence response. The response body contains details of each client present on the channel and the channel they are present on. The status code for a successful response is always 200:

[
  {
    "channel":"channel0",
    <a href="[">presence</a>
      {"clientId": "user1", "action": "1"},
      {"clientId": "user2", "action": "1"}
    ]
  },
  {
    "channel":"channel1",
    <a href="[">presence</a>]
  },
  {
    "channel":"channel2",
    <a href="[">presence</a>
      {"clientId": "user2", "action": "1"},
      {"clientId": "user3", "action": "1"}
    ]
  }
]

Copy
Copied!

The following is an example of a batch presence failure response. The response body contains the details of the error, in this example that the token used for the request has expired. The status code is 401:

{
  "error": {
    "message":"Token expired",
    "statusCode":401,
    "code":40140
  }
}

Copy
Copied!

The following is an example of a batch presence partial success response. The successful requests contain the details of each client present on the channel, and the channel they are present on. The failed request contains the channel the request failed for and the details of the error, in this example that the credentials used didn’t have the capability to query that channel. The status code for a partial success is always 400:

{
  "error": {
    "message": "Batched response includes errors",
    "statusCode":400,
    "code":40020
  }
  "batchResponse": [
    {
      "channel":"channel0",
      <a href="[">presence</a>
        {"clientId": "user1", "action": "1"},
        {"clientId": "user2", "action": "1"}
      ]
    },
    {
      "channel":"channel1",
      <a href="[">presence</a>]
    },
    {
      "channel":"channel2",
      "error": {
        "message": "Given credentials do not have the required capability",
        "statusCode": 401,
        "code": 40160
      }
    }
  ]
}

Copy
Copied!

Using the request() method with the REST interface of an Ably SDK requires handling responses for success, failure and partial success.

A response object will have response.success set to true if the batch presence request was successful, and false if at least one individual presence request failed. The response.statusCode will be set to 200 for success, 400 for partial success and 401 for an expected failure. response.errorCode will then contain the Ably error code and response.errorMessage will contain the details of the error.

response.items will contain a list of responses for each channel for which presence has been requested in a successful response. response.items.batchResponse will contain a list of each channel’s results, be it an error or a success for a partially successful response. The response.errorCode will always be 40020 for a partial success.

The following is an example of handling the various responses:

REST
JavaScriptPHP
Select...

var ablyRest = new Ably.Rest({ key: '<loading API key, please wait>' })
const content = { 'channel': 'channel1,channel2' }
const presenceSets = await ablyRest.request('GET', '/presence', null, content, null);
console.log(presenceSets.success);
console.log(presenceSets.errorCode);


if (presenceSets.success) {
  // If complete success
  for (i = 0; i < presenceSets.items.length; i++) {
    // Each presenceSets item will be roughly of the style:
    /*
      {
        'channel': 'channel1',
        'presence': [
          { 'action': 1, 'clientId': 'CLIENT1' },
          { 'action': 1, 'clientId': 'CLIENT2' }
        ]
      }
    */
  }
} else if (presenceSets.errorCode === 40020) {
  // If partial success
  for (i = 0; i < presenceSets.items[0].batchResponse.length; i++) {
    // Each batchResponse item will either be the same as success if it succeeded, or:
    /*
      {
        'channel': 'channel1',
        'error': {
          'code': 40160,
          'message': 'ERROR_MESSAGE',
          'statusCode': 401
        }
      }
    */
  }
} else {
  // If failed, check why
  console.log(presenceSets.errorCode + ', ' + presenceSets.errorMessage);
}

API Key:
Demo Only
Copy
Copied!

History provides access to instantaneous “live” history as well as the longer term persisted history for presence channels. If persisted history is enabled for the channel, then presence events will be stored for 24 or 72 hours, depending on your account package. If persisted history is not enabled, Ably retains the last two minutes of presence event history in memory.

Any time a channel is re-attached and the presence set is re-synced, e.g. after a short disconnection, the client will check whether any members it has entered into the presence set are there. If not, it will automatically re-enter them. This means that if a channel loses continuity (for example, because a client was disconnected from Ably for more than two minutes before reconnecting), then after the channel automatically re-attaches, any presence members it had previously entered will be restored.

The exception is if you use the recover feature to resume a previous connection with a fresh SDK instance (for example, to have continuity over a page refresh). In that case you will need to explicitly re-enter presence after you re-attach to the channel, due to the loss of SDK internal state.

Clients that are part of a presence set remain present for 15 seconds after they are abruptly disconnected, for example where the internet connection suddenly drops or the client is changing networks. This delay is to avoid repeated leave and enter events being sent when a client is experiencing an unstable connection.

The Ably SDK will attempt to reconnect after a disconnect. If the connection is reestablished before 15 seconds have passed, a leave event will not be sent. If the connection is reestablished after 15 seconds, a leave event will be sent and the presence set will need to be rejoined.

Note that the 15 second delay from being removed from the presence set is only for abrupt or unplanned disconnects. If a client calls leave() or close() they immediately send a leave event.

The time taken before a leave event is sent in the case of an abrupt disconnect can be reduced to a minimum of 1 second by setting a value for remainPresentFor, in milliseconds. This property is set within the transportParams property of the clientOptions object.

It is important to note that it can initially take up to 30 seconds to identify that a client has been abruptly disconnected. Shorten the amount of time taken to identify abrupt disconnects using the heartbeatInterval property if your app needs to quickly identify presence set members being abruptly disconnected.

The following example code demonstrates establishing a connection to Ably with remainPresentFor set to 1 second:

JavaScriptNode.jsFlutterJava
Select...
const ably = new Ably.Realtime(
  {
    key: '<loading API key, please wait>',
    transportParams: { remainPresentFor: 1000 }
  }
);
API Key:
Demo Only
Copy
Copied!