We really like the async model with web sockets. In some of our applications, we implement widgets in frames (often as many as 10 or 20 widgets on a page). Each widget opens a
It depends on the browser.
See:
It seems that the maximum number of possible open Websockets is defined by the browser implementation, and it is being difficult to find numbers.
In the Chromium source code (Google Chrome for Linux) I can see a max of 30 per host, 256 overall.
// Limit of sockets of each socket pool.
int g_max_sockets_per_pool[] = {
256, // NORMAL_SOCKET_POOL
256 // WEBSOCKET_SOCKET_POOL
};
// Default to allow up to 6 connections per host. Experiment and tuning may
// try other values (greater than 0). Too large may cause many problems, such
// as home routers blocking the connections!?!? See http://crbug.com/12066.
//
// WebSocket connections are long-lived, and should be treated differently
// than normal other connections. 6 connections per group sounded too small
// for such use, thus we use a larger limit which was determined somewhat
// arbitrarily.
// TODO(yutak): Look at the usage and determine the right value after
// WebSocket protocol stack starts to work.
int g_max_sockets_per_group[] = {
6, // NORMAL_SOCKET_POOL
30 // WEBSOCKET_SOCKET_POOL
};
In the Firefox configuration, (go to about:config
and search for network.websocket
) I can see a max of 6 persistent connections per host and 200 overall, but apparently the persistent conection limit does not affect WebSocket connections, so only the 200 limit applies.
My recommendation is that you should use one per page/tab. If you have widgets as frames, use .postMessage
( +info ) to communicate between frames and the main page, and let the main page communicate with the server with a single connection. Use a publisher/subscriber model to allow different widgets subscribe to particular events.
Having so many connections is a waste of resources in both browser and server.