Pusher.com FAQs

When using a Content Security Policy (CSP) you might notice an outbound request to *stats.pusher.com. This is used to anonymously collect usage statistics for Channels.

There is no impact to preventing these connections, and we offer a flag to turn off this stat collection entirely. See our GitHub repo for more information.

An example connection using this in Javascript might look like:

var pusher = new Pusher({ appId: 'ID', key: 'KEY', secret: 'SECRET', cluster: 'eu', disableStats: true});

In order to downgrade your account, you need to click on one of the Downgrade buttons in Channels Billing page of the dashboard.

Why does the downgrade not work immediately?

Your plan will not be immediately downgraded. Instead, you will remain on the current plan until your billing period ends, at which point you will be automatically downgraded. When you have a pending downgrade, you will see a banner in the dashboard which shows the date that you will be downgraded.

The Plans & billing page on the dashboard will continue to show your old plan until the downgrade date.

Pusher delays downgrades in this way so you can continue to make use of the higher plan for the period of time that you have paid for. Our service is not pro-rated, so you cannot claim a refund for the period of time between initiating a downgrade and the end of your billing period.

We are currently in the process of completing a dashboard unification project between our Channels dashboard and Beams/Chatkit dashboard. You may have already seen some changes!

Currently we have a known issue where, if you have signed up for one of our dashboards with your Google or Github account, you cannot sign up for the other dashboard with the same account without following a few steps.

If you already have already registered your Google or Github account with our Channels dashboard at https://dashboard.pusher.com and then try and register or sign in with the same account at https://dash.pusher.com for Beams/Chatkit you will see the following error message:

https://dash.pusher.com/authenticate/reset-password

Trying to register the account will present the following error message:

At this stage you need to take the following action:

1) Navigate to

2) Enter your Google or Github email address and click "Reset your password":

3) Wait for the password reset email to be delivered to your inbox and click the "Reset Password" button in the email

4) Enter and confirm your new password and click "Change Password":

5) On the sign in page sign in with your email address and new password:

6) While logged into the Beams/Chatkit dashboard click Account in the top right and click "Settings" in the dropdown:

7)Under OAUTH Providers select either "Connect Google account" or "Connect GitHub account" to link the relevant account. Follow the login workflow of the selected provider:

8) You should now see that your account has been linked:

9) In future you will be able to log into the dashboard with your Google or Github account

We are currently in the process of completing a dashboard unification project between our Channels dashboard and Beams/Chatkit dashboard. You may have already seen some changes!

Currently we have a known issue where, if you have signed up for one of our dashboards with your Google or Github account, you cannot sign up for the other dashboard with the same account without following a few steps.

If you have already registered your Google or Github account with our Beams/Chatkit dashboard at https://dash.pusher.com and then try and register or sign in with the same account at https://dashboard.pusher.com for Channels you will see the following error message:

https://dashboard.pusher.com/accounts/password/new

At this stage you need to take the following action:

1) Navigate to

2) Enter your Google or Github email address and click "Submit:

3) Wait for the password reset email to be delivered to your inbox and click the "Reset your password" link in the email

4) Enter your new password in the box and click "Change my password":

5) On the sign in page sign in with your email address and new password:

6) While logged into the Channels dashboard click the dropdown in the top right and click "Channels Settings":

7) Under Connected Accounts select either "Connect Google account" or "Connect GitHub account" to link the relevant account. Follow the login workflow of the selected provider:

8) You should now see that your account has been linked:

9) In future you will be able to log into the dashboard with your Google or Github account

By default multiple Channels webhooks are batched into one POST request before being sent to your webhook endpoint. This is to reduce the number of requests being sent if you generate a large number of webhooks in a short period of time.

Webhooks are batched for a maximum of 250ms or until 20 webhook events have been added to the batch before being sent to your webhook endpoint.

WebSocket connections generally work even if a proxy or firewall is in place. This is because they use ports 80 and 443 which are also used by HTTP connections.

In some situations WebSocket connections are blocked over port 80. In this case a secure SSL connection using WSS over port 443 should successfully connect. If this is not the case please contact Pusher support.

The destinations and ports used by Channels clients are as follows:

on port 80on port 443

If you have subscribed to a cluster other than mt1 then the destinations and ports used by Channels clients are as follows:

on port 80on port 443

If pusher-js is used and a fallback transport is used (such as xhr_streaming), the destinations and ports used by Channels clients are as follows:

on port 80on port 443

If you have subscribed to a cluster other than mt1 than the destinations and ports used bu Channels clients are as follows:

on port 80on port 443

If pusher-jsis used and it is a version before 3.0.0 then, if Flash is required as a fallback (e.g. the browser does not natively support WebSockets), the following addresses and ports may attempt to be used via a direct TCP connection:

ws.pusherapp.com on port 80ws.pusherapp.com on port 443

If making use of the CDN then the following are used:

js.pusher.com on port 80js.pusher.com on port 443

For the server libraries you will need:

api.pusherapp.com on port 80api.pusherapp.com on port 443

Although, if you have subscribed to a cluster other than mt1, then you will require:

api-[your-cluster].pusher.com on port 80api-[your-cluster].pusher.com on port 443

Finally, our optional stats collection endpoint requires:

stats.pusher.com port 80stats.pusher.com port 443

The message count is calculated based on:

All calls to our REST API e.g. publish a message, query information on a channel, client-events

Messages delivered to connected clients, including client-events

WebHook calls made from the Pusher service to your application WebHook endpoint

If you use presence channels within your application then messages are triggered when users join (pusher:member_added) and leave (pusher:member_removed) a channel.

Ping/pong messages used to detect dropped connections and subscription command messages are not counted towards the message count.

A Calculation example of Publishing & Subscribing

When a message (event) is triggered on a channel and pushed into Pusher it is then distributed to all connected clients that are subscribed to that channel. So, if one message is published on my-channel and 50 clients are subscribed to that channel then the message count will be 51.

var messagesPublished = 1;var subscribingClients = 50;var totalMessages = messagesPublished + (subscribingClients * messagesPublished);// 1 + (50 * 1)alert(totalMessages); // 51

An example with bigger numbers and more messages published, but still with a single channel would be where there are 500 subscribed clients and 40,000 messages published. The 40,000 messages would be delivered to all 500 connected clients resulting in 20,000,000 messages being delivered. So the total message count would be 20,000,000 + 40,000:

var messagesPublished = 40000;var subscribingClients = 500;var totalMessages = messagesPublished + (subscribingClients * messagesPublished);// 40000 + (500 * 40000)alert(totalMessages); // 20040000

The example above highlights the need to use channels to filter messages so that clients only received the information they are really interested in. Let's take an example with the following scenario:

there are 100 channels used to filter the data into categories

100 clients are interested in all events on all channels

100 clients are interested in data from 50 channels

the remaining 300 clients are subscribed to just 1 channel

the 40000 messages are distributed between all channels leading to 400 messages per channel

The message consumption values would be as follows:

100 clients receive all messages on all channels = (100 * 400 * 100) = 4,000,000 messages

100 clients receive messages on 50 channels = (100 * 400 * 50) = 2,000,000 messages

300 clients receive messages on 1 channel = (300 * 400 * 1) = 120,000 messages

Which is a total of 6,120,000 messages delivered. Add that to the number of messages published means that 6,160,000 messages in total.

Although quite complicated this hopefully shows that by filtering the messages using channels that the number of messages delivered can be vastly reduced. In the case above the number of messages delivered has decreased by a massive 13,880,000.

More

More information on message quotas please see the plans on our pricing page.

You can update the email address that you use to login to your Beams and Chatkit account by logging into the Pusher dashboard and following these steps:

Navigate to "Account" and select "Settings".

Enter your updated email address under the "Email" section.

Click "Change Email"

Acknowledge the confirmation email by clicking the link.

You can update the email address that you use to login to your Channels account by logging into the Channels dashboard and following these steps:

Navigate to Channels Settings in the dashboard.

Enter your updated email address under General settings.

Enter your current password into the "Current Password" box (This is required for email address changes).

Click "Update Channels settings".

Acknowledge the confirmation email by clicking the link.

You can downgrade your Chatkit subscription by navigating to the Billing Dashboard and choosing "Manage" next to Chatkit.

You will then be taken to a page where you can select the plan you require.

You can upgrade your Chatkit subscription by navigating to the Billing Dashboard and choosing "Manage" next to Chatkit.

How can I downgrade my Chatkit plan?

You will then be taken to a page where you can select the plan you require.

Once selected you will be able to enter your billing and payment details.

For instructions on how to downgrade visit

We are aware of an issue that is preventing account details provided during Chatkit/Beams sign up from propagating to the Channels management dashboard.

As a workaround for this issue, follow the below steps:

1) Go to dashboard.pusher.com2) If you have previously set a password for this account (not via google) chose to "Log in with email"3) If you haven't set a password before click "Forgot you password" and generate a reset email. Follow the instructions to set a new password4) Return to log in page and login with email/password (not google)5) If you have successfully logged in go to Account Settings and scroll down to the bottom and under connected accounts connect up your google account

Problem:

When integrating Channels with apps for iOS and Android, a common questionis how to manage the Channels appkeys and secrets required to connect the mobile appto Pusher.

As thekeys canrequire changingat times, we recommend that you implementa processto manage this change.This can become necessary, for example, when a key has becomecompromised.

As a general recommendation, you should use different Channels app credentials foreach application you need to connect to your Channels app (e.g. mobile apps, server-side processes, Javascript on your website).This ensures that if a key becomes compromised, only that key needs to be changed and other applications will not be impacted.In the Dashboard for your app you can create additional app credential sets as required:

Solution:

There are generally two approaches to solving this, each with their own advantagesand disadvantages.

Key Included in the App

The most straightforward way of supplying the mobile app with the required key is to include it in the app's codeor package.

This requires no further involvement or maintenance unless the key needs to be changed.If this does happen, a new release of the app through Google Play or the App Store isnecessary that includes the updated key.

Key drawbacks of this approach are:

* The turnaround time for publishingnew version can be quite long.

* Not all users will installthe updatequickly.

*For a period, multiple credentials need to be maintained so that all app versions continue to function.

* If a keyis actively being abused, it will be impossible to counteract this without shutting down your app entirely.

This method is good for apps where the keys arechanged infrequently as it requires no additional overhead once the app is published unless a key needs changing.

In that event, create a new credential pair for your corresponding Channels app in the Dashboard and include it in the next version of your mobile app.Do not delete the old pair as this would cause existing installations of yourapp to fail.Pusher is unable to restore credentials thathave been deleted.After the new version has been rolled out throughGoogle Play or the App Store, you will need to wait until most users have installed the update before finally deleting the old credentials onthe Dashboard.

Keys Supplied from Server

To ensure you can change keys quickly without impairing the functionality of your mobile apps, you can store your keys securely on a server you control and provide them in an encrypted form to theapps on request - instead of including the keys in eachapp itself.

In this scenario, your mobile app will make a request to your server each time it starts (or immediately before connecting to Channels) to retrieve the current credentials.The app will need a way to authenticate and decrypt the response which cannot easily be replicated outside of your app (e.g. by using a shared secret or certificate-based authentication).

This approach allows you to change app keys within minutes and minimal disruption to your app but has the drawbackrequiring a highly available application server without which your app will not function.

When using this technique, you can change keys by creating a new pair, updating your server with it and removing the old one once most apps have picked up the change.

To view the billing statements for your Channels account:

Log in to https://dashboard.pusher.com

Click on the "Channels Billing" button in the left hand menu bar

Scroll to the bottom of the page

View the recent list of statements under "Billing history"

Download the relevant statement by clicking the "Download" button

Warning the following steps will lead to your account being deleted. This cannot be undone.

Log into your Pusher Channels account dashboard

Click on the dropdown arrow in the top right corner and click "Channels Settings"

Scroll down to the bottom of this page and click the "Delete account" button.

Confirm your account password and delete the account

You can update your payment details (including credit cards) by logging into your Pusher account at https://dashboard.pusher.com/

You'll need the account details that were originally used to create the account, so if you're not the account owner you may need them to do this for you.

Click on"Channels Billing" button in the left menu bar

Clickthe "Update Payment Details" button on the new page under the "Update billing information" section

If you can't do this or have further problems, please log a support ticket using the link below.

Currently, within Chatkit, there is a limit of 1,000 rooms that a user can be a member of.The reason for this is that, beyond that number, we are aware that customers may start to encounter issues with some of Chatkit's functionality. To prevent these issues, when a user connects to Chatkit we only send unread counts and last message id's for a maximum of 1000 rooms

We are aware that this restriction may be problematic for some of our customers and it is something we are actively reviewing and looking to resolve. An example use case would be a tutor who has on-going 1-to-1 open chats with many (1000+) students.

As best practice we would always recommend that a user leaves a room when the chat is deemed completed. If this is not possible and a user needs to remain a member of more than 1,000 rooms then, taking the tutor/student use-case above, we suggest that at the point the chat is deemed complete the tutor is removed from the room. If the room names are configured to be tutorid:studentid then, when the student posts a message you can use a Message Created Webhook to detect that the message has been sent and then add the tutor back into the relevant room, using the studentid from the webhook body to identify the appropriate room.

This will mean that the tutor will only be a member of rooms which have active conversations taking place and will only be re-added to a room when a student posts a message.

As discussed this limitation is something we are aware of and are actively working to resolve, as such, if you have a use case which the suggestion above will not work for we would be very keen to hear from you via our support page: https://support.pusher.com/hc/en-us/requests/new

If you need to share access to an app you can follow the below steps:

1) Log into the dash

2) Click on the ChatkitInstances link and select the target instance

3) Click on the settings tab and scroll down to the Collaborators section.

4) Input the collaborator's email address and click Invite

This will allow you to invite others to share access to this app.

If you need to share access to an app you can follow the below steps:

1) Log into the dash

2) Click on the Beams Instances link and select the target instance

3) Click on the settings tab and scroll down to the Collaborators section.

4) Input the collaborator's email address and click Invite

This will allow you to invite others to share access to this app.

A full explanation of HIPAA requirements is beyond the scope of this FAQ. We recommend becoming familiar with HIPAA requirements and technical best practices, as they apply to you based on your legal assessment.

In general it is relatively simple to comply with HIPAA requirements when using Pusher products.

Pusher does not currently sign Business Associate Agreements with customers. Instead, we recommend that you avoid transmitting Protected Health Information (PHI) via Pusher products. When using Pusher in this way, Pusher is not a business associate, because its activities do not involve the use or disclosure of protected health information.

A typical practice to achieve this is to instead transmit opaque identifiers of PHI, which recipients can then use to fetch the PHI from your system. For example, suppose you are building a postal prescription service, which needs to display a realtime list of pending orders in each pharmacy. You can implement this using Pusher Channels. Since these orders contain PHI, you should not transmit their details via Pusher Channels. Instead, give each order an opaque ID, and transmit this ID to the client. When the client receives a new order ID, it should then use it to fetch the order details from your server (using your existing auth mechanisms).

While the example above is for Pusher Channels, the same practice applies to Pushers other products including Beams and Chatkit.

If you have further questions, we're happy to help! Please contact [email protected]

As part of GDPR compliance you may be required to understand the providers in use by Pusher.

These are as follows:

Amazon Web Services

Cloud hosting provider

Google Cloud Platform

Cloud hosting provider

Heroku

Platform as a Service; uses AWS physical infrastructure and handles managementdeployment/maintenance of databases

Looker

Business Intelligence Web Application with a read-only connection to Pushers data warehouse

The backend API version used by our 0.x beta series SDKs has been removed after a long period of deprecation. It was critically important to drop support for these SDK versions in order to evolve the API further. If you are experiencing request failures with "api_version_removed" errors, upgrade to a 1.x series SDK.

Previously, when your 1 to 1 Chatkit chat room triggered a push alert, the notification showed up with the room name as the title like this:

Updating the push notification title override on a room

We have now changed the default behaviour, so push notifications for 1 to 1 chat rooms (i.e. private rooms with exactly two members) will display the name of the messages author as the title like this:

If you want revert to the previous behaviour (i.e, room name as the title), please follow these steps to override the changes:

Creating a room with a push notification title override

If you have any further questions or concerns on the topic please raise a support ticket and we will be able to help you.

Presence channels can be extremely powerful because it can expose an awareness of who is subscribed to that channel. However the ability to always keep track of users in the channel can generate a large number of messages: How is my message count calculated in Channels?

The reason for this is as follows:

Imagine you have a channel for to keep track of participants in a game.To implement this, FooBar use Pusher Channelspresencechannelfeature. For game 123, they have the channelpresence-game-123. When player 42 subscribes to this channel, he receives the full current set of other players, and amember_addedevent is broadcast to all other subscribers. When player 42 unsubscribes(ordisconnects), amember_removedevent is broadcast to the remaining subscribers.

A typical FooBar game has 600 players, and each player stays for an average time of 60 seconds. By Littles Law, we know that 600/60 = 10 new clients arrive every second. Clients leave at the same rate, so 10 clients also leave every second. Each arrival triggersamember_addedevent, and each departure triggers amember_removedevent, so we have 10+10 = 20 triggered events per second. Each event is broadcast to the entire group of 600, consuming 600 messages from FooBars quota. So the presence channel for this game consumes 20 * 600 = 12,000 messages per second! This is over one billion messages per day!

As you can see from the above the number of messages generated can be come large very quickly. For implementing large presence channels see: How can I implement large presence channels on Channels?

Channels has a large list of official and community supported libraries which can be found here

As well as the official documentation linked to each of these SDKs we have a large number of tutorials that can help you get started with Channels. Our tutorials page can be found here

Examples of the technologies covered are as follows:

Android

Javascript

Javascript / AngularJS / React / Gatsby

iOS

Swift /ObjectiveC

.NET

Java

Go

NodeJs

PHP

PHP / Laravel

Ruby

Arduino

C++

Clojure

Coldfusion

Dart

Flutter

Elixir

Grails

Groovy

Haskell

Ionic

Perl

Python

React Native

QML

Scala

Beams has a number of official and community supported libraries which can be found here

As well as the official documentation linked to each of these SDKs we have a large number of tutorials that can help you get started with Beams. Our tutorials page can be found here

Examples of the technologies covered are as follows:

Android

iOS

Swift / ObjectiveC

Go

PHP

NodeJS

Python

Java

Ruby

React Native

Laravel

Rust

Dart

Chatkit has a number of official and community supported libraries which can be found here

As well as the official documentation linked to each of these SDKs we have a large number of tutorials that can help you get started with Chatkit. Our tutorials page can be found here

Examples of the technologies covered are as follows:

Android

Javascript

Javascript / AngularJS / React

iOS

Swift

React Native

Node

Ruby

Go

PHP

PHP / Laravel

Python

Ionic

Channels makes it really easy to add real-time data and functionality to web, mobile and IoT apps. For use cases such as notifications and signalling, that data can be transient, where the data is only relevant for a short period of time. In other cases, such as activity streams or chat, data may need to be persisted and historical data is as important as the data delivered via real-time updates.

This article covers:

How and when to retrieve a history of messages

For this article it is assumed that your application persists messages prior to sending them via Pusher.

There is also a tutorial that covers an example in detail. You can read it on the Pusher blog.

How and when to retrieve a history of messages

Being able to see a history of messages within a chat application provides context to the ongoing conversation. When you think about how you would add this functionality there are three choices that generally come to mind:

Choice

Will it work?

1. Generate static HTML for the existing messages on the server

No. Messages could be missed between the HTML being sent to the client and the subscription on the client taking place.

2. Fetch data upon connection

No. The client hasn't subscribed to the channel yet so any messages sent prior to the subscription could be missed.

3. Fetch data upon successful subscription

Yep. This way you will get any new data via Pusher and can retrieve all historical data from your server.

You should fetch the historical messages from the server after successfully subscribing to the channel. The basic flow to achieve this is:

The application loads

Connect to Pusher

Subscribe to the channel

Bind to the pusher:subscription_succeeded event on the channel

Bind to the new_message event to be notified when any new chat messages arrive via Pusher

Upon successful subscription, retrieve the messages from the server

Add the messages to the UI, ensuring that those messages are sorted and no duplicates exist from any messages that may have come in via Pusher during the retrieval

How Can I Get Missed Messages After Reconnecting To Channels?

Retrieve Missed Messages Upon Subscription

The pusher:subscription_succeeded event is emitted from at channel once Pusher has acknowledge a subscription request. It is at that point at which historical messages should be retrieved.

In the following JavaScript example a retrieveHistory handler function will be called when the subscription has succeeded:

var pusher = new Pusher(PUSHER_CHAT_APP_KEY);

var chatRoom = this.pusher.subscribe('messages');

chatRoom.bind('pusher:subscription_succeeded', retrieveHistory);

The purpose of the retrieveHistory function is to fetch messages from your server. As an example, the following code will make an AJAX call to retrieve the chat message history:

function retrieveHistory() {

$.get('/messages').success(function(response) {

// TODO: extract messages from the response

});

},

In this example the /messages endpoint would need to return a number of existing messages. How it does that and how many it returns depends on your solution.

From here you need to add those messages to your application UI.

Adding Historical Messages to the UI

Now that the existing chat messages are being returned to the client they need to be shown in the UI.

When adding them to the UI it's important to check two things:

That duplicates don't occur

The ordering of messages in the UI is correct

The suggested solution to this is to have a sequence ID for each message so it's very easy to detect duplicates and determine the correct order of messages. If you are using a database solution, the Primary Key for each message within your database may be sufficient.

Follow Up

Now that you have an API for retrieving historic messages it is easy to implement a solution for when a client temporarily disconnects. See

Unfortunately, we can not give out a list of our IP addresses. The reason for this is that our system is comprised of Amazon EC2 boxes that are load balanced by ELB, and we frequently add and remove boxes as we need to scale up and down, as well as take down crashed boxes and perform maintenance. We do this to maintain the best possible level of service to our customers.

Unfortunately, we can not give out a list of our IP addresses. The reason for this is that our system is comprised of Amazon EC2 boxes that are load balanced by ELB, and we frequently add and remove boxes as we need to scale up and down, as well as take down crashed boxes and perform maintenance. We do this to maintain the best possible level of service to our customers.

Unfortunately, we can not give out a list of our IP addresses. The reason for this is that our system is comprised of Amazon EC2 boxes that are load balanced by ELB, and we frequently add and remove boxes as we need to scale up and down, as well as take down crashed boxes and perform maintenance. We do this to maintain the best possible level of service to our customers.

Warning the following steps will lead to your account being deleted. This cannot be undone. Deleting this account will impact both your Chatkit and Beams apps.

Log into your Pusher Chatkit/Beams account dashboard ( https://dash.pusher.com/ )

Click "Account" in the top right corner

Scroll down to the bottom of this page and click the "Delete Account" button.

Confirm your account password and delete the account

Chatkit instances are only available as a hosted solution and it is not possible to deploy these on premise. However, as long as you have an internet connection available your application should be able to connect to Chatkit from your internal systems.

Channels apps are only available as a hosted solution and it is not possible to deploy these on premise. However, as long as you have an internet connection available your application should be able to connect to Channels from your internal systems.

Our documentation details the official libraries and SDKs that are updated and supported by Pusher.

We also share the community libraries. These libraries are built by members of the Pusher Channels Developer Community. They are potentially incomplete and are therefore not officially supported by Pusher. It's recommended that you first reach out to the maintainer of the library before contacting support.

If you need to share access to an app you can follow the below steps:

1) Log into the dashboard2) Click on the app you would like to share3) Scroll to the bottom and click on the "Add Collaborators" button on the right hand side. This will allow you to invite others to share access to this app.

4) Repeat 1-3 for any other apps you would like to share.

How to implement large presence channels on Pusher Channels

Introduction

Pusher Channels has a feature called "presence channels. When used at scale, this feature leads to a very high message rate. This document shows why that message rate is high, then suggests some ways you can adjust your UX requirements to enable lower message rates, then shows how you can implement these alternatives using tools provided by Pusher Channels.

The Ux Requirements

The Problem: Too Many Presence Events

How to Relax the UX Requirements

Tools Provided by Pusher to Implement Relaxed Requirements

Example Relaxed UX Requirements

How to Implement these Relaxed Requirements

In the Future

The UX requirements

Assume FooBar Inc hosts online multiplayer games. While player 42 is in game 123, player 42 will see an up-to-date list of all other players who are in game 123.

The problem: too many presence events

To implement this, FooBar use Pusher Channels presence channelfeature. For game 123, they have the channel presence-game-123. When player 42 subscribes to this channel, he receives the full current set of other players, and a member_added event is broadcast to all other subscribers. When player 42 unsubscribes (or disconnects), a member_removed event is broadcast to the remaining subscribers.

A typical FooBar game has 600 players, and each player stays for an average time of 60 seconds. By Littles Law, we know that 600/60 = 10 new clients arrive every second. Clients leave at the same rate, so 10 clients also leave every second. Each arrival triggers a member_added event, and each departure triggers a member_removed event, so we have 10+10 = 20 triggered events per second. Each event is broadcast to the entire group of 600, consuming 600 messages from FooBars quota. So the presence channel for this game consumes 20 * 600 = 12,000 messages per second! This is over one billion messages per day!

This throughput is deemed unacceptable. This is the problem we seek to fix.

How to relax the UX requirements

As the above calculation shows, the high message rate problem follows directly from the requirements. Therefore, in order to reduce this message rate, one or more requirements must be relaxed. Here are some requirements and how they might be relaxed:

The realtime requirement. It may be unnecessary for the player to have a completely up-to-date view of the other players.

Alternative 1: only show the initial value on page load, then have no further updates.

Alternative 2: batch updates. Every 10 seconds, send the latest member_added and member_removed events.

The full set requirement. It may be unnecessary for the player to have access to the full set of other players.

Alternative 1: show a subset of the other players, e.g. the oldest 20 players.

Alternative 2: show a counter, e.g. 245 people are playing.

The accuracy requirement. It may be unnecessary for the player to know the exact set, or the exact number of other players in the set.

Alternative: show an approximate counter, with client-side jitter.

These adjustments to the requirements can be combined in many ways - too many to list here. Instead, we show the tools that Pusher Channels provides for implementing these combinations, and then show one example set of relaxed requirements, and how these could be implemented using Pusher Channels.

Tools provided by Pusher Channels to implement relaxed requirements

Pusher Channels provides three tools you can use to implement these relaxed requirements: the member presence events toggle, and server-side presence and channel existence info. Below, well see how you can combine these three tools to achieve an example set of requirements.

Member presence events toggle. If this is on (the default), Pusher Channels will send member_added and member_removed events. If this feature is turned off, Channels only sends the initial presence set on subscription, but then does not keep the client up-to-date. Unfortunately, this toggle is currently only exposed to admins - please contact support quoting your app ID, and well turn this off for you. (We plan to expose this toggle in the dashboard in future; see the end of this doc.)

Presence HTTP API. From your server, you can fetch a full snapshot of the members for a given presence channel. (Alternatively, you can fetch just the number of members in a given presence channel. This is more efficient than fetching the full list.)

Channel existence HTTP API. From your server, you can fetch a full list of channels beginning with a prefix, e.g. presence-game-.

(In addition to polling our HTTP APIs, you can use webhooks to receive this data with lower latency. However, implementing this reliably can be more complex, so in this document, we stick to polling HTTP APIs.)

Example relaxed UX requirements

FooBar Inc hosts online multiplayer games. While the player is in the game, the player will see two things: a list of up to 5 players, plus an approximate count of the total number of other players. This could look like the UI below. Both are refreshed every 60 seconds, but the counter UI updates every second with simulated client-side jitter. If the player clicks on the 711 other players counter, they see the full list of players.

These requirements lead to a much lower message rate: 600/60 = 10 messages per second, or 0.08% of the original message rate!

How to implement these relaxed requirements

Contact support with your app ID, and request that member presence events are toggled off for your app.

When your client subscribes to presence-game-123, it will receive the full initial set of other players. Use this to construct the initial UI, taking an example subset and the total count, and then throw away the rest.

On your server, every 60 seconds, fetch the full list of channels with the prefix presence-game-, then for each of these channels, fetch the full member list. For each channel, take up to 5 players from the list, and the total, then trigger a presence-update event with a body of the form {"players": ["p1", "p2", "p3", "p4"], "total": 711}.

Your client should bind to the event presence-update on the presence channel. On receipt of such an event, the client will refresh the UI.

On your client, every second, either increment or decrement the counter. This provides a realtime experience, without the expense.

On your server, expose a /presence/:channel endpoint, which will serve the full presence list to your clients.

When the user clicks on the 711 other players counter, the client should make a request to /presence/presence-game-123 for the full presence list, then display this. (Alternatively, the client could display the list it was originally served on subscription. This is simpler and more efficient, but the list will become stale.)

This error comes from Pushers server when you're trying to subscribe to a private / presence channel. It happens because of the token mismatch: your client is not receiving the correct signature from your auth endpoint. The error is reported on the client side, this is why you see it in Client Logs in Dashboard.

There are three variables that matter to generate a valid auth token: a secret key, a channel name, and a socket id. So the problem is in one of them. Double check in your server and client code that these values are correct. This page shares more information about authentication mechanism: https://pusher.com/docs/channels/library_auth_reference/auth-signatures Here's what happens: when a new pusher object is creating on a client, it calls your auth endpointthe auth endpoint on your server signs a token using the authenticate method of our server library your client gets the token from the auth endpoint your client attempts to subscribe to a presence channel with that token the token signature is invalid, and "Expected HMAC SHA256 hex digest..." is reported in your error logs.You can't catch those errors server side, but you can catch those errors on a client and then send the info to your server with some special library (example: https://www.bugsnag.com/platforms/javascript/). If you use js-library the code snippet will look something like this:

pusher.connection.bind( 'error', function( err ) { if (err.error.data.message.includes("Invalid signature")) { <send the error log to your server> };

For a full, up to date list of our Channels Clusters visit https://pusher.com/docs/channels/miscellaneous/clusters#what-clusters-exist-

Currently our Chatkit service resides in the US, on Chatkit Cluster US1. As the service grows we may deploy further clusters.

For information on how this relates to data storage and relevant laws (e.g GDPR), see Where does Chatkit store data?

Prerequisites

The solution discussed below assumes there is some sort of message history store implemented on you application server. To implement such a store, you can review the guidance at How do I implement message (event) history for Channels? before continuing.

How to retrieve messages missed during periods of network instability

Sometimes a client will lose Internet connectivity. When that happens new messages won't be able to be delivered to that client.

The Pusher libraries maintain a list of channels that an application is subscribed to. Therefore, upon reconnection they can automatically re-subscribe to those channels. The benefit of this is that the functionality implemented to retrieve historical messages can also be used for this connectivity scenario because the pusher:subscription_succeeded event will once again be triggered resulting in the historical message retrieval logic being exercised.

The only addition that is required is for the call to the server to also pass an ID of the last message is presently has. If you have followed the link in the prerequisite then this was referred to as thesequence ID that was to be used to detect duplicate messages and sort existing messages.

Assuming you have theretrieveHistory function from the prerequisite, the function can be updated as follows:

function retrieveHistory() {

var lastId = getLastMessageSequenceId();

$.get('/messages', {after_id: lastId}).success(function(response) {

// TODO: add missed messages to the UI

});

},

As before, you should check for duplicates and the order of your messages within the UI.

Conclusion

By following the techniques it is easy to use the events that the Pusher libraries expose to add historical data to an application and also fetch any missed messages during periods of network instability.

If we have been unable to take payment for your Pusher subscription you will receive an email from us as follows:

Subject:[Pusher] We couldn't charge your card.Body:Hello {customer name},We just tried to process your current amount due of $XX.XX for your Pusher {Product} subscription, but the credit card XXXX-XXXX-XXXX-XXXX charge was declined.The reason given for the declined transaction was: {Reason provide by your bank}To continue your service without interruption, update the credit card on file as soon as possible.Please use the following link to update your billing information: https://pusher.chargifypay.com/update_payment/{id}/{id} Sincerely, The Pusher Team

The most common reason for this to happen is that the credit card you have setup for us to charge has expired and the details need updating. You can update the card details in the Pusher dashboard, for further instructions see How can I update my billing details for Channels?.

Please note that we attempt to take payment once a day so you may need to wait up to 24 hours for payment to go through after you have updated/added the payment method.

If your credit card details are valid then we would suggest doing either of the following:

Raise a support ticket so that we can investigate the status of the transaction.

Contact your card provider for advice as to why the card has been declined.

We haven't had any reports of problems, but we haven't tested in China ourselves so we can't give a firm answer. While were not aware of any issues using Pusher Channels in China, wecan'treally make any guarantees of service due to China's networking restrictions.

We don't host Pusher Channels in China, but we have AWS regions in Asia: Mumbai, Singapore and Tokyo. Please refer to our documentation for more information about regions: https://pusher.com/docs/channels/miscellaneous/clusters#what-clusters-exist-

Due to the way Heroku provisions Channels apps no emails are sent by default. Instead Heroku Users will need to follow the below process to add your email address to begin receiving these emails.

When your account approaches its message or connection limits we will send the Channels account owner an email warning them of this. We will also send another email once this limit has been reached.

It is also possible to add additional email contacts, slack integration or trigger a webhook. This can be done as follows:

1) Log into the https://dashboard.pusher.com

2) Click the dropdown arrow in the top right and select "Limit Notifications"

3) Select the "Notification Type" from the dropdown and add the "Destination"

4) Click "Test" or "Save limit notification" to add this.

When working with the Chatkit libraries in VSC you may come accross the following error

Could not find a declaration file for module '@pusher/chatkit-client'. '/usr/node_modules/@pusher/chatkit-client/dist/web/chatkit.js'

implicitly has an 'any' type.

Try `npm install @types/pusher__chatkit-client` if it exists or add a new declaration

(.d.ts) file containing `declare module '@pusher/chatkit-client';`" ts(7016)

This error should not prevent your code from running. However, to prevent the error from being displayed you can simply create a'chatkit.d.ts'file at the same level as your 'Chatscreen.js' file with the contents declare module '@pusher/chatkit-client'; This should allow VSC to overlook the lack of typing and instead import the module with theanytyping.

Channels are "server-side" message filters. If a client isn't subscribed to a channel they won't get messages on those channels. This means it is advantageous to subscribe to lots of tightly scoped Channels rather than only subscribing to one or two channels where you send messages that not all clients will necessarily be interested in. If you only send messages that clients want you reduce the amount of data being sent to the client and also reduce your messages count!

In short designing your application with lots of Channels for specific subjects is better practice than subscribing to few very busy Channels.

There is no limit on the number of Channels that you can subscribe to:

What are the maximum number of channels supported per application?

It is not possible to schedule events in the dashboard. These can only be sent on an adhoc basis. You would need to implement this functionality yourself programmatically. A simple solution to do this may be to create a cron (or other scheduled) task - that can trigger a POST request to our HTTP API:

https://pusher.com/docs/rest_api#method-post-event

If you see the error "There was a problem creating your WebHook, please try again" while trying to add a Channels WebHook you need to make sure that the WebHook endpoint exists. As part of the validation process, the URL is checked in DNS to make sure that it exists.

For example if you add the WebHook URL http://mynonexistenturl.com this will fail because it isn't found by DNS.

You can check that your URL does return a result in DNS by using nslookup:

https://en.wikipedia.org/wiki/Nslookup

Presence Channels

Webhooks for presence channels are specifically delayed in order to debounce temporary disconnections and member removals. If a user disconnects and then reconnects within 3 seconds, neither event will be delivered via webhook.

Multiple Connections

Another scenario is when there are multiple connections with the same user_id, they are treated as the same user; webhooks won't be triggered for all events on all sockets.

Server Error

There is another scenario where your server which receives webhooksis down. Your server should respond to the POST request with a 2XX status code to indicate that the webhook has been successfully received. If a non 2XX status code is returned or the endpointcan'tbe reached, Channels will retry sending the webhook, with exponential backoff, for 5 minutes.

If you are experiencing a problem with webhooks not being sent in any other scenario, please provide screenshots or logs (it would be useful to know specific times that you are aware the problem is occurring) with details before contacting us at [email protected].

TheWebSocket is closed before the connection is establishederror message indicates that some client code, or other mechanism, has closed the websocket connection before the connection was fully established.

If the connection eventually succeeds then the message can be safely ignored.

If you are using Google Chrome you may need to restart your browser. We've seen that after Chrome updates there is sometimes a network issue which stops WebSocket connections from succeeding.

If you are still having issues please contact us using the button below.