tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SPDY support
Date Wed, 15 Feb 2012 19:58:55 GMT
On Wed, Feb 15, 2012 at 10:31 AM, Mark Thomas <markt@apache.org> wrote:

> On 15/02/2012 16:11, Costin Manolache wrote:
> > After I submit, I'll give a try to changing SocketWrapper (non-generic,
> > add read/write), in the git. If you don't like it - easy to drop the
> branch,
> > but I think it'll simplify the old connectors enough to compensate for
> the
> > extra complexity I'm adding :-)
>
> Sounds good.
>
> > Well, UpgradeProtocol has read/write methods, I would drop the streams
> > ( keep them as separate util classes if someone wants them).
> > I would also drop the methods reading/writing a single byte, use only
> > byte[].
>
> I'd love to drop the streams and just use the message based API but the
> WebSocket protocol design is such that it needs to support streaming to
> stand any chance of being remotely scalable / efficient given the
> frankly crazy maximum message size.
>

I think it's not as bad, and crazy-size frame can be split - users need a
callback
when a new message started, than can call UpgradedProtocol.read([]) until
the
 message is done.

In spdy I'm using a SpdyFrame class ( spdy allow data frames to be
fragmented any
way you want by intermediary - so even if I receive a huge frame, I can
split it
in buffer-sized frames  - I believe you can do the same for websocket, as
long as you
preserve the message boundaries), and return the real buffer to avoid the
copy required
for read(b[]). But of it involves a releaseBuffer().
Take a look - if/when we have websocket-over-spdy it would be good to be
consistent.

Costin


>
> Maybe after things have bedded in for a while, we'll see which API folks
> are using and if there is zero demand for the stream based API we can
> drop that part and simplify the code accordingly.
>


>
> > I think most improvements I can think of involve removing code :-)
>
> Those are always my favourite changes.
>
> 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