On 10 October 2011 23:52, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> Ok, so this test is about the old comet model in your specific
> implementation, placed in an ideal usage scenario. Nice, but how is this
> relevant ?
>
It is as relevant as any single data point can be. It shows that at least
in some circumstances blocking is not a problem.
> The main problem is that without non blocking controls on output, your
> websocket server can be easily taken down by a handful of slow clients.
> Either because it uses a single thread to send data back (it would
> become unresponsive), or because the unwritten data will need to be
> fully buffered across all clients (it would OOM). This is actually a DoS
> class security issue for any application that needs to send back
> sizeable amounts of data.
>
But we already have a blocking API for
servletResponse.getWriter().write(somedata);
Servlets can block and hold a container thread today. Having a blocking
sendMessage is no different to what we already have for servlets. Yes there
are DOS attacks that can be based on this blocking style, but you have to
get the server to send you a large HTTP response or a large WS message or
lots and lots of small WS messages. Async IO is better in this regard, but
async can be a tough application API for application/framework developers.
> BTW, I also continue to believe having control over frames is useful,
> but this is not the place to discuss this.
>
In the context of a JSR specifically for WS, I agree that it should have
full access to frames, opcodes, extensions and other stuff hidden from the
javascript clients.
It is only in the context of the servlet specification that I'm advocating a
minimal application level only API.