Multiple Points of Presence (MPoP)
Spark Communications Services allows your application to have multiple instances running and connected at the same time for the same user. This ability is referred to as having Multiple Points of Presence, or MPoP.
The MPoP feature works by managing two distinct aspects of a user's representation within the system.
An identity is represents one of your application's user accounts within the BlackBerry Infrastructure. Typically every human user has one account with your application and thus one MPoP identity.
An endpoint is the client application that runs with the credentials, access, and capabilities of that identity.
In MPoP, each identity can run multiple endpoints simultaneously. Each endpoint can send and receive messages, start and leave chats, mark messages as read, etc.
Spark Communications Services supports two kinds of endpoints.
Persistent endpoints are created and exist for a long time. The Android and iOS versions of the SDK are persistent endpoints. Typically, this type of endpoint exists until the application is uninstalled. When running, these endpoints are always either connected or waiting to connect to the BlackBerry Infrastructure. The endpoints proactively receive messages and securely store them persistently in local storage.
Ephemeral endpoints are created for a short period of time and come and go frequently, such as when a web page is loaded and then closed. The Web and Node versions of the SDK are ephemeral endpoints. Ephemeral endpoints lack persistent storage and often are concerned with only a small subset of the chats and messages that are available to an identity. Most importantly, they aren't expected to last for a long time like an application on Android and iOS.
Persistent endpoints can be used offline even when they aren't connected to the BlackBerry Infrastructure. Ephemeral endpoints do not have persistent data so there is only limited functionality when no connection to the BlackBerry Infrastructure is available.
Spark Communications Services limits the number of endpoints of each type that an identity can have connected to the BlackBerry Infrastructure at the same time. The way that these limits are enforced reflects the differences between the two types of endpoints.
The BlackBerry Infrastructure limits each identity to a maximum of three concurrently registered persistent endpoints and seven concurrently registered ephemeral endpoints. Your application must expect these limits to change at any time for new and existing identities. The SDK does provide information about the current limits when performing Endpoint Management.
Persistent Endpoint Management
Persistent endpoints are expected to be entities that the end user is aware of. For example, a user knows that they have a copy of your application running on their Android phone and another copy on their iOS tablet. Your application can use the Endpoint Management features of the SDK to list what endpoints are registered, give each endpoint a name and description, or deregister an endpoint from their identity.
When a persistent endpoint is created, it first registers with the BlackBerry Infrastructure. If it passes various security checks, it is allowed to connect. When the BlackBerry Infrastructure detects that the maximum number of persistent endpoints has already been reached, your application must deregister one or more of the existing persistent endpoints to make room for the new one. Alternatively, your application can decide to deny the registration of the new endpoint.
Persistent endpoints have the ability to list and manage ephemeral endpoints.
Ephemeral Endpoint Management
The management of ephemeral endpoints is more automatic. These endpoints are created for brief use, so it is important that they are cheap and easy to make. When an ephemeral endpoint registers with the BlackBerry Infrastructure and the maximum number of ephemeral endpoints has already been reached, the BlackBerry Infrastructure selects a less-active, older ephemeral endpoint and automatically deregisters it. Ephemeral endpoints that are deregistered do not automatically try to reregister, but they do allow your application to reregister them (which might deregister another ephemeral endpoint).
Ephemeral endpoints do not have the ability to list or manage any types of endpoints.
All endpoints of the same identity see the same data at the same time if they are all connected to the BlackBerry Infrastructure. When endpoints are offline for a short time and then come back online, they synchronize by receiving messages and other information from the BlackBerry Infrastructure, like a single endpoint does when it disconnects and then reconnects.
Examples of information that is synchronized across an identity's endpoints include:
- Which chats an identity is participating in and the metadata of those chats, including the subject and participant list
- The messages within a chat
- The delivery status ('D' and 'R') of messages for the identity and other participants
Some state information and data is local to an endpoint and is not synchronized with other endpoints of the same identity. Sometimes this is because the data only pertains to the endpoint, and sometimes this is because the state hasn't propagated to other endpoints yet.
Examples of information that is not synchronized across an identity's endpoints include:
- Chats created locally on an endpoint but not yet created on the BlackBerry Infrastructure
Chats in the
- The list of hidden chats
- Old chats and old messages that are no longer available from the BlackBerry Infrastructure's storage
- Outgoing messages that have not been posted
- Failed outgoing messages
- Attachments that are not yet uploaded
- Attachment upload and download progress
- Which attachments are downloaded
All endpoints in an identity use the same identity keys and chat keys, and all endpoints have access to the same user keys.
If your application uses the BlackBerry Key Management Service, the SDK synchronizes all of these keys across all endpoints automatically.
If your application uses Cloud Key Storage, then when it fetches and stores keys as directed by the SDK, all of these keys are kept synchronized across all endpoints.