Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 27, 2010 at 11:45 AM, John Tamplin wrote: > On Thu, May 27, 2010 at 10:28 AM, Simon Pieters wrote: >> >> From our testing it seems that Vista has a limit of 1398 open sockets. >> Apparently Ubuntu has a limit of 1024 file descriptors per process. > > On Linux, that is just the default (which may vary between distros) and can > be configured by the administrator -- see ulimit -n, sysctl -w fs.file-max, > and fs.file-max in /etc/sysctl.conf (location may var between Linux > distros). I think it is reasonable to assume that the browser must be able to operate effectively within those default limits, though: mostly the browser can't adjust those, or usefully instruct the user to do so. Mike
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 27, 2010 at 10:28 AM, Simon Pieters wrote: > From our testing it seems that Vista has a limit of 1398 open sockets. > Apparently Ubuntu has a limit of 1024 file descriptors per process. > On Linux, that is just the default (which may vary between distros) and can be configured by the administrator -- see ulimit -n, sysctl -w fs.file-max, and fs.file-max in /etc/sysctl.conf (location may var between Linux distros). -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, 13 May 2010 16:47:34 +0200, Simon Pieters wrote: On Wed, 12 May 2010 20:01:11 +0200, Ojan Vafai wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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. Why? Is the concern that we'd run out of memory? Overload the user's network connection? If nothing else, the underlying OS might have a limit on the number of open connections. From our testing it seems that Vista has a limit of 1398 open sockets. Apparently Ubuntu has a limit of 1024 file descriptors per process. On low-end devices and low-end networks, it seems likely that there's a relatively low limit on the number of connections. -- Simon Pieters Opera Software
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 9:00 PM, Boris Zbarsky wrote: > On 5/13/10 7:55 PM, Perry Smith wrote: >> Its not that hard and it won't happen that often. And it gives >> the javascript authors more control and choices. > > If a situation doesn't happen often, then historically speaking most authors > will have no provisions to handle it. Try browsing the web with non-default > colors set in your browser, with a default font size that's not 16px, or with > a 13px minimum font size set. These aren't exactly hard things to deal with, > but authors just don't deal with them. I sincerely doubt they'd deal with > the possibility of a websocket not actually opening unless is was _very_ > common. > > Maybe the spec should say that attempts to open a websocket should have a 50% > chance of failing even if there's no good reason for it, just so it is in > fact common for opening to fail? ;) (No, that's not a completely serious > proposal, but it's not completely facetious either; it would take something > like that for authors to handle failure properly.) That wasn't what I meant. "it won't happen often" I meant, the need to have a queueing mechanism written in Javascript. i.e. most applications of web sockets would want to just fail. The few that do not, can roll their own.
Re: [whatwg] WebSockets: what to do when there are too many open connections
On 5/13/10 7:55 PM, Perry Smith wrote: Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. If a situation doesn't happen often, then historically speaking most authors will have no provisions to handle it. Try browsing the web with non-default colors set in your browser, with a default font size that's not 16px, or with a 13px minimum font size set. These aren't exactly hard things to deal with, but authors just don't deal with them. I sincerely doubt they'd deal with the possibility of a websocket not actually opening unless is was _very_ common. Maybe the spec should say that attempts to open a websocket should have a 50% chance of failing even if there's no good reason for it, just so it is in fact common for opening to fail? ;) (No, that's not a completely serious proposal, but it's not completely facetious either; it would take something like that for authors to handle failure properly.) -Boris
Re: [whatwg] WebSockets: what to do when there are too many open connections
I think that queuing in chrome bends the intent of the createWorker api just a little too far and will be happy to see it go away. I'd rather it failed outright then pretend to succeed when it really hasn't. (Actually that queuing code complicates the impl somewhat too... can you tell its been annoying me recently ;) On Thu, May 13, 2010 at 5:36 PM, Dmitry Titov wrote: > As an example from a bit different area, in Chrome the Web Workers today > require a separate process per worker. It's not good to create too many > processes so there is a relatively low limit per origin and higher total > limit. Two limits help avoid situation when 1 bad page affects others. Once > limit is reached, the worker objects are created but queued, on a theory > that pages of the same origin could cooperate, while if a total limit is > blown then hopefully it's a temporary condition. Not ideal but if there > should be a limit we thought having 2 limits (origin/total) is better then > have only a total one. > > On Thu, May 13, 2010 at 4:55 PM, Perry Smith wrote: > >> >> On May 13, 2010, at 12:40 PM, Mike Shaver wrote: >> >> > The question is whether you queue or give an error. When hitting the >> > RFC-ish per-host connection limits, browsers queue additional requests >> > from or such, rather than erroring them out. Not sure that's >> > the right model here, but I worry about how much boilerplate code >> > there will need to be to retry the connection (asynchronously) to >> > handle failures, and whether people will end up writing it or just >> > hoping for the best. >> >> Ah. Thats a good question. (Maybe that was the original question.) >> >> Since web sockets is the topic and as far as I know web sockets are only >> used by javascript, I would prefer an error over queuing them up. >> >> I think javascript and browser facilities have what is needed to create >> its own retry mechanism if that is what a particular situation wants. I >> don't see driving the retry via a scripting language to be bad. Its not >> that hard and it won't happen that often. And it gives the javascript >> authors more control and choices. >> >> Thats my vote... >> >> pedz >> >> >
Re: [whatwg] WebSockets: what to do when there are too many open connections
As an example from a bit different area, in Chrome the Web Workers today require a separate process per worker. It's not good to create too many processes so there is a relatively low limit per origin and higher total limit. Two limits help avoid situation when 1 bad page affects others. Once limit is reached, the worker objects are created but queued, on a theory that pages of the same origin could cooperate, while if a total limit is blown then hopefully it's a temporary condition. Not ideal but if there should be a limit we thought having 2 limits (origin/total) is better then have only a total one. On Thu, May 13, 2010 at 4:55 PM, Perry Smith wrote: > > On May 13, 2010, at 12:40 PM, Mike Shaver wrote: > > > The question is whether you queue or give an error. When hitting the > > RFC-ish per-host connection limits, browsers queue additional requests > > from or such, rather than erroring them out. Not sure that's > > the right model here, but I worry about how much boilerplate code > > there will need to be to retry the connection (asynchronously) to > > handle failures, and whether people will end up writing it or just > > hoping for the best. > > Ah. Thats a good question. (Maybe that was the original question.) > > Since web sockets is the topic and as far as I know web sockets are only > used by javascript, I would prefer an error over queuing them up. > > I think javascript and browser facilities have what is needed to create its > own retry mechanism if that is what a particular situation wants. I don't > see driving the retry via a scripting language to be bad. Its not that hard > and it won't happen that often. And it gives the javascript authors more > control and choices. > > Thats my vote... > > pedz > >
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 12:40 PM, Mike Shaver wrote: > The question is whether you queue or give an error. When hitting the > RFC-ish per-host connection limits, browsers queue additional requests > from or such, rather than erroring them out. Not sure that's > the right model here, but I worry about how much boilerplate code > there will need to be to retry the connection (asynchronously) to > handle failures, and whether people will end up writing it or just > hoping for the best. Ah. Thats a good question. (Maybe that was the original question.) Since web sockets is the topic and as far as I know web sockets are only used by javascript, I would prefer an error over queuing them up. I think javascript and browser facilities have what is needed to create its own retry mechanism if that is what a particular situation wants. I don't see driving the retry via a scripting language to be bad. Its not that hard and it won't happen that often. And it gives the javascript authors more control and choices. Thats my vote... pedz
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:40 PM, Mike Shaver wrote: > I have to admit, I'd be a little surprised (I think pleasantly, but > maybe not) if I could open ten thousand file descriptors on the latest > shipping Windows CE, or for that matter on an iPhone. ulimit -n tells me I can only open 1024 per process on my desktop and server Linux machines. Actually, I had to configure lighttpd on my server to raise its max file descriptors to 4096 to make sure it could handle all my keepalive connections (although maybe it could have anyway).
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:19 PM, Perry Smith wrote: > Hosts have limits on open file descriptors but they are usually in the ten's > of thousands (per process) on today's OSs. I have to admit, I'd be a little surprised (I think pleasantly, but maybe not) if I could open ten thousand file descriptors on the latest shipping Windows CE, or for that matter on an iPhone. The question is whether you queue or give an error. When hitting the RFC-ish per-host connection limits, browsers queue additional requests from or such, rather than erroring them out. Not sure that's the right model here, but I worry about how much boilerplate code there will need to be to retry the connection (asynchronously) to handle failures, and whether people will end up writing it or just hoping for the best. Mike
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Thu, May 13, 2010 at 1:19 PM, Perry Smith wrote: > >>> [[ > >>> 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. > >>> ]] > >>>I don't think this is an area for the spec. The open must be allowed to > fail if something goes wrong. The OS might reject it and the browser might > reject it too. Aside from that, I don't think the spec should dictate what > to do here. > > A nice UA, I think, would monitor a particular tab or browsing context for > being out of control. This might be opening an infinite number of sockets > or running infinite threads to bog the user's system down (or it might be > because I forgot a semicolon :-). There are countless ways for nasty > javascript to upset the user. A nice UA from a nice group would learn these > new ways and adapt to them over time. When detected, the UA could ask the > user if they want this mayhem to continue or not. I think rampant socket > abuse is just one of countless places nasty javascript is going to exploit > the user. I don't see how the spec can foresee all of them nor should a > "complaint UA" be required to detect all of them. > I think simply saying that a user agent may restrict the number of connections like the server might is sufficient. As written, it implies the number is actually unlimited. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] WebSockets: what to do when there are too many open connections
On May 13, 2010, at 10:05 AM, Simon Pieters wrote: > On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman > wrote: > >> On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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. Hosts have limits on open file descriptors but they are usually in the ten's of thousands (per process) on today's OSs. I don't think this is an area for the spec. The open must be allowed to fail if something goes wrong. The OS might reject it and the browser might reject it too. Aside from that, I don't think the spec should dictate what to do here. A nice UA, I think, would monitor a particular tab or browsing context for being out of control. This might be opening an infinite number of sockets or running infinite threads to bog the user's system down (or it might be because I forgot a semicolon :-). There are countless ways for nasty javascript to upset the user. A nice UA from a nice group would learn these new ways and adapt to them over time. When detected, the UA could ask the user if they want this mayhem to continue or not. I think rampant socket abuse is just one of countless places nasty javascript is going to exploit the user. I don't see how the spec can foresee all of them nor should a "complaint UA" be required to detect all of them. Perry Ease Software, Inc. ( http://www.easesoftware.com ) Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, 12 May 2010 20:51:59 +0200, Michael Nordman wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, 12 May 2010 20:01:11 +0200, Ojan Vafai wrote: On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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. Why? Is the concern that we'd run out of memory? Overload the user's network connection? If nothing else, the underlying OS might have a limit on the number of open connections. -- Simon Pieters Opera Software
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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. > > -- > Simon Pieters > Opera Software >
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, 2010-05-12 at 11:01 -0700, Ojan Vafai wrote: > On Wed, May 12, 2010 at 4:31 AM, Simon Pieters > 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. > > > > Why? Is the concern that we'd run out of memory? Overload the user's > network connection? > > > Ojan I would imagine primarily it's out of concern for the remote host. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] WebSockets: what to do when there are too many open connections
On Wed, May 12, 2010 at 4:31 AM, Simon Pieters 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. Why? Is the concern that we'd run out of memory? Overload the user's network connection? Ojan
