On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman <[email protected]>
wrote:
On Wed, May 12, 2010 at 4:31 AM, Simon Pieters <[email protected]> wrote:
establishing a WebSocket connection:
[[
Note: There is no limit to the number of established WebSocket
connections
a user agent can have with a single remote host. Servers can refuse to
connect users with an excessive number of connections, or disconnect
resource-hogging users when suffering high load.
]]
Still, it seems likely that user agents will want to have limits on the
number of established WebSocket connections, whether to a single remote
host
or multiple remote hosts, in a single tab or overall. The question is
what
should be done when the user agent-defined limit of established
connections
has been reached and a page tries to open another WebSocket.
I think just waiting for other WebSockets to close is not good. It just
means that newly loaded pages don't work.
Agreed, not good. The intent of the api is to start opening a socket now,
not at some undefined point in the future after the user has taken some
undefined action (hey user... please close a tab that has a socket
open...
not particularly user actionable).
If there are any WebSockets in CLOSING state, then I think we should
wait
until they have closed. Otherwise, I think we should force close the
oldest
WebSocket.
Force closing the oldest is not good. A malicious site could cause all
open
sockets to be closed. Also this would have nasty side effects. Consider a
memory allocator that just deleted the oldest allocation to make room for
new allocations, far removed things just start failing on odd ways... no
thank you.
An obvious way to handle this condition of "too many sockets are open"
is to
fail to open the new socket with an exception/error which indicates that
condition.
But then to make the page work the user still has to close a tab that has
a socket open. But maybe just firing a 'close' event and logging in the
error console is the best thing to do.
--
Simon Pieters
Opera Software
