On Thu, Feb 2, 2012 at 3:33 AM, Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
