tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
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 <markt@apache.org> wrote:

> On 29/01/2012 01:20, Costin Manolache wrote:
> > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas <markt@apache.org> 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
nio/apr/oio
input/output are implemented in Internal[Input/Output][Nio/Apr]Buffer which
are
quite heavy- it would be a huge change to modify that. However it may be
possible
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
likely,
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
the
string conversions for text frames in a low-level interface.

Costin


>
> Thanks for the feedback. Much appreciated.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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