On 15/02/2012 03:53, Costin Manolache wrote: > Uploaded another take. > > This time I'm just adding > https://github.com/costinm/tomcat/blob/trunk/java/org/apache/tomcat/util/net/LightHandler.java > > which is just a Handler - like AjpConnectionHandler, > Http11ConnectionHandler. > > I believe this is as close to Endpoint intent as it can be - given this is > a protocol at the same level with Ajp or http11. > > The only thing special is that the Endpoint must have both the regular > Http11ConnectionHandler and a SpdyHandler - and chose one or the other > based on TLS negotiation result. > > Sorry for not providing enough background: SPDY as specified and > implemented by browsers only works over TLS, and only if the server > negotiates it using the NPN TLS extension ( which only works for openssl - > so APR ). Firefox doesn't support any 'non secure' mode, Chrome can be > started with some parameters (--use-spdy=no-compress,no-ssl), but won't be > able to connect to google or other spdy servers.
Ah. That explains quite a few things. I was beginning to get that impression but the draft specs I was looking at didn't make that clear at all. > I added it to the JIO endpoint for testing - and because I believe it is a > great protocol for internal server-to-server connections, in which case no > browser is involved and you can set it without ssl ( and without the header > compression, which is another requirement ). Thanks. The fog is starting to lift now. >>> On Tue, Feb 14, 2012 at 9:36 AM, Mark Thomas <ma...@apache.org> wrote: >>>> > I hope the new interface does - it's just a small extension to Handler ( > the main method is > present in all other protocol implementations ) I haven't had a chance to look at it yet but I wanted to respond to the rest of your points. >> Does it need the socket or are input and output streams sufficient? > > It needs the APR socket to call JNI getNPN. > > I could make it work with the UpgradeAprProtocol eventually (making the > socket available), > but it feels more complex and intrusive, there are too many extra things. Fair enough. It may be that UpgradeXXXProtocol ends up extending the LightProtocol. Given the relative complexities / baggage if anything extends anything that seems the way to go right now (keeping in mind I haven't looked at your new code at all yet). > Processor is tied to one request/response - Spdy protocol is a multiplexing > protocol, so one spdy connection will have 100s of Requests. > I am using Processor interface for each muxed spdy stream. Hmm. I wonder if we need a different name than Processor just to clarify the difference? But that is more a cosmetic issue. > Plus - both are quite rich objects. I think it's worth using a smaller > interface > ( i.e. Endpoint.Handler with few extra extensions). I'd be prepared to trade a little bit of extra baggage (as I have with much of the connector refactoring) to increase commonality between components and reduce code duplication. What that means for SPDY I don't know yet. Again, I need to look at your latest proposal. This is more a general statement of the compromises I am happy making for easier maintenance. > I don't think the LightHandler will affect the rest of the protocol code - > it is pretty well separated, doesn't leak into coyote. Let me look at the latest proposal. > The main point is that SPDY is selected after the TLS hanshake. > ( with the benefit of saving one roundtrip - which is needed for websocket > upgrade). As above, this dependency wasn't clear to me based on what I read. Things make a lot more sense now. >>> Also: the current upgrade is quite heavy, it holds Requet/Response and a >>> bunch of >>> buffers. >> >> No it doesn't. Take another look at the code. The original >> implementation did but as I stated at the time my intention was to do >> some further refactoring to fix that. That refactoring has been complete >> (and is what resulted in the API changes I was referring to previously). > > Yes, much better now ! ( but still I don't think it's the best fit ). Thanks. Suggestions for improvements welcome. > I would be happy to use the interfaces for websocket-over-spdy. Great. >> Having skimmed the latest SPDY draft spec at this point, it looks more >> like a protocol switch would be required rather than running WebSocket >> over SPDY. The protocols look to have a lot in common and I'm not sure I >> see the point of running WebSocket over SPDY. >> > > The point is that one TCP connection ( and more important - one TLS > handshake ) > is used for all websocket and GET/POST requests for a site. > If you have a page that uses websocket - and also has many resources, uses > ajax, etc - it'll end up as a single long-lived TCP connection for all of > them. Got it. > SPDY can't be used with NIO - JSSE doesn't have the 'next protocol > negotiation' > extension which is required by SPDY. Again, got it. >> That assumes that there is only a single TCP connection between HTTPD >> and Tomcat. I'm not sure how valid that would be given that HTTPD is >> typically multiple processes and that most production configurations I >> see have multiple HTTPDs and multiple Tomcats that all talk to each >> other. Whether there would be enough connections to justify NIO I don't >> know. > > I don't mind adding the 'intranet'/server-to-server to NIO - but I would > first wait to see real proxies or frontends that use spdy. Works for me. >> It isn't completely clear to me - even after looking through your patch >> - how a SPDY connection is initiated. Could you provide pointers to the >> starting points for non-TLS and TLS connections? >> > > If you use a browser - TomcatAprHandler, the key is: > > SSLExt.checkNPN(socket, SpdyContext.SPDY_NPN) > > If TLS negotiated spdy -> the AprSpdyFramer ( which implements Handler ) > will > be used, and the normal http handler will be skipped. Thanks. That will help. > For non-SSL ( JIO, and apr without ssl ) -> SPDY just kicks in on all > connections, Ah. Light dawns. Do you see a requirement for non-SSL connections to be able to use HTTP or SPDY in the same way SSL ones can? For the proxy use case, an assumption of all SPDY seems valid. > this is just a short-cut for testing. I could also define a SpdyProtocol > and set it > directly on the connector - but seems too much overhead for something that > is testing/experimental. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
