tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: WebSocket progress report
Date Sun, 29 Jan 2012 22:49:05 GMT
On Sun, Jan 29, 2012 at 2:19 AM, Mark Thomas <> wrote:

> On 29/01/2012 01:20, Costin Manolache wrote:
> > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas <> wrote:
> >
> > Not complaining - it's great to add this feature, please commit it - but
> > I'm wondering
> > if a lighter interface wouldn't be better. From looking at the
> > implementation, it seems
> >  after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole
> >  Request / Processor / etc tree ).
> I agree there is certainly scope to do that. My initial focus has been
> on functionality and minimal changes to existing code - hence the
> current approach.
> I'm not overly keen on the additional overhead myself and can see
> several ways to reduce it. Output is easier than input since we know the
> output buffers are clear on upgrade. Input is a little trickier since
> there may be some data in the input buffer and that would need to be
> drained before switching to the lighter weight approach.

I don't think the upgrade protocol allows clients to send payload before
receiving the response
headers / handshaking, so I think it wouldn't be a problem.

In terms of actual code changes - I think the main problem is that
input/output are implemented in Internal[Input/Output][Nio/Apr]Buffer which
quite heavy- it would be a huge change to modify that. However it may be
to have some lighter buffers - just the socket and methods to read/write.
At least that's what I've been trying with spdy - which also involves some
protocol switching.
The change is also minimal in endpoint-specific code ( it's just adding few
hooks and some new code ).

I think this is something to look at once the implementation is more
> feature complete. Whatever we do, I'd like to keep the following aims in
> mind:
> - minimal endpoint specific code
> - minimal changes to what we have now
> - keep the generic upgrade and the protocol specific parts separate

I agree.

> > Would it be possible for example to release the Request, like it's done
> > after request,
> > in keep-alive, and use a lighter parser/callback on the socket ? I think
> > one of the use cases
> >  for websockets is to support a _lot_ of open connections.
> That is certainly one approach. It will be easier to explore options
> when we have a wider range of examples to work / test with.
> > Also the interface may be simpler without InputStreams.
> I thought long and hard about that. Looking around, some implementations
> are message based, some are stream based. There are good arguments for
> both. Unfortunately the WebSocket protocol is a messages based protocol
> with no maximum message length. A message is one or more frames and a
> frame is up to 2^63 bytes. While most usages will be small(ish) messages
> that can be buffered without undue overhead, any application that wants
> larger messages needs to use a stream based interface to be able to
> scale. That is why I went for both.

Well, the message is sent from javascript - I don't think 2^63 frames are
and even if they are, I don't think a blocking InputStream interface is
best choice.

Why not copy some of the javascript interface ( onopen / onmessage / etc )
Or onMessage(byte[] initialData) + onMessageData(byte[] moreBytes) ?
In other words - make it 'async' from start.  I wouldn't even worry about
string conversions for text frames in a low-level interface.


> Thanks for the feedback. Much appreciated.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message