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 Thu, 02 Feb 2012 14:14:10 GMT
On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas <markt@apache.org> wrote:

> On 02/02/2012 10:05, Remy Maucherat wrote:
> > On Wed, 2012-02-01 at 13:54 -0800, Costin Manolache wrote:
> >> Hi,
> >>
> >> Some initial patch for SPDY - using the NPN SSL extension, as required
> by
> >> chrome/firefox.
> >>
> >> I used github so it's easy to add comments or test:
> >>
> >>
> https://github.com/costinm/tomcat/commit/e97def3314216c083cc4b68ad9731e5a94b2af28
> >>
> >> Basic 'hello world' works in both jio and apr, looking for opinions on
> the
> >> integration with tomcat connectors.
> >> Please let me know :-)
> >
> > Ok, I think your "light protocol" concept to group any "upgraded"
> > connections is appropriate.
>
> Agreed. I'll see if I can wrap this into the generic upgrade process I
> added as part of the WebSocket support.
>

My concern with the current upgrade process added for WebSocket is that
it's very heavy
in memory use. I think it would be better to go the other way - and use the
 LightProtoocl for WebSockets. If the app needs the original
Request/Response - we could
save them, but in most cases I don't think they'll be needed.

On use: I think next version of Firefox will also support SPDY, of course
Chrome. It seems
to be faster than HTTPS - and it's lighter on the server as well, fewer
connections.

It is also a very good protocol for web frontend ( load balancer, etc ) to
tomcat - i.e.
a possible replacement for AJP or simple HTTP proxy, in particular if you
expect
a lot of long-lived connections ( comet or websockets ).

Remy: I don't think websockets is 'stream' based, just our current
implementation uses
InputStream to abstract long messages ( which I don't like either ).

The websocket protocol is message based - but the messages can be 'text'
or 'binary'.
I would guess most real-life web apps will send/receive text json, but it
doesn't
mean our implementation  must make a big distinction - it could just send
bytes.

Costin


>
> 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