The packets are automatically buffered when the client is disconnected, and will be sent upon reconnection. That's why Socket.IO includes a heartbeat mechanism, which periodically checks the status of the connection.Īnd when the client eventually gets disconnected, it automatically reconnects with an exponential back-off delay, in order not to overwhelm the server. Under some particular conditions, the WebSocket connection between the server and the client can be interrupted with both sides being unaware of the broken state of the link. This feature was the #1 reason people used Socket.IO when the project was created more than ten years ago (!), as the browser support for WebSockets was still in its infancy.Įven if most browsers now support WebSockets (more than 97%), it is still a great feature as we still receive reports from users that cannot establish a WebSocket connection because they are behind some misconfigured proxy. The connection will fall back to HTTP long-polling in case the WebSocket connection cannot be established. Here are the features provided by Socket.IO over plain WebSockets: HTTP long-polling fallback Please use a dedicated messaging platform like FCM for this use case. The Socket.IO library keeps an open TCP connection to the server, which may result in a high battery drain for your users. Socket.IO is not meant to be used in a background service for mobile applications. Here's a basic example with plain WebSockets: JavaScript (for WeChat Mini-Programs):.JavaScript (which can be run either in the browser, in Node.js or in React Native).

JavaScript (Node.js) (whose documentation can be found here on this website)Īnd client implementations in most major languages:.

There are several Socket.IO server implementations available: WebSocket is a communication protocol which provides a full-duplex and low-latency channel between the server and the browser.

Socket io express