- Ably FAQs
- Ably architecture, transports, and security
- Transports and connections
-
Account billing and packages
-
General
-
Realtime API and client libraries
-
Troubleshooting
-
Channels
-
REST API and client libraries
-
Ably error codes
-
Account and app setup and configuration
-
Ably architecture, transports, and security
-
Performance and Redundancy
-
Push Notifications
-
Integrations
-
Migrating to Ably from an existing service
Why is the Realtime SDK always establishing Comet connections for long polling rather than using it as a fallback for WebSockets?
Caution: From v2 of the javascript library the behaviour described on this page has changed:
See the v2 migration guide links below
As mentioned on which transports are supported, when a browser client library first connects to Ably to establish a realtime connection, by default the library initiates connection using comet. It then attempts to upgrade the Comet connection to a websocket connection. Typically this happens within a few seconds.
We took this approach because there are a few environments in which websockets are subtly broken (eg some corporate proxies); using a Comet transport first gives a connection that works for everyone as quickly as possible, after which we can try the upgrade to websockets at leisure.
If you want a different behaviour, you can do that with ably-js client options, with the `transports` option. To force immediate websockets (bypassing the upgrade step), you can initialise the client library as follows:
new Ably.Realtime({ transports: ['web_socket'], ...(other client options) })
If you require any further questions, do let us know on support@ably.com