Hello there, I'm currently looking into implementing the SPDY [1] protocol based on Warp. I read in the archives that Daniel Sommermann wanted to start something similar for snap-server but I haven't seen any updates for some time. So if you've got a finished implementation somewhere in your drawer this would be a great time to publish it ;) Otherwise I'd start with the parser for the framing layer. SPDY compresses some parts of the frames using zlib. Michael already merged a small patch I wrote into zlib-bindings to support initial dictionaries so I think I'm ready to go there. Another thing that is needed to fully support SPDY is TLS. I think I'd use the tls library by Vincent here. There is some implementation work needed in the library for an extension called NPN (next protocol negotiation) which SPDY uses. Vincent offered to help here. Thanks :) (By the way, although it's possible to force at least Chrome to use non-encrypted connections "it'll break all sorts of things" according to the SPDY book [2]). With this post I'd like to start a discussion about the implementation and interfaces of this so the result can be reused in other contexts (e.g. for Snap). If you've got any suggestions and sources of inspiration I'm happy to hear them. Best regards, Robin [1] http://dev.chromium.org/spdy [2] http://spdybook.com/
On Mon, Jan 9, 2012 at 10:07 PM, Robin Brandt
Hello there,
I'm currently looking into implementing the SPDY [1] protocol based on Warp. I read in the archives that Daniel Sommermann wanted to start something similar for snap-server but I haven't seen any updates for some time. So if you've got a finished implementation somewhere in your drawer this would be a great time to publish it ;)
Otherwise I'd start with the parser for the framing layer. SPDY compresses some parts of the frames using zlib. Michael already merged a small patch I wrote into zlib-bindings to support initial dictionaries so I think I'm ready to go there.
Another thing that is needed to fully support SPDY is TLS. I think I'd use the tls library by Vincent here. There is some implementation work needed in the library for an extension called NPN (next protocol negotiation) which SPDY uses. Vincent offered to help here. Thanks :) (By the way, although it's possible to force at least Chrome to use non-encrypted connections "it'll break all sorts of things" according to the SPDY book [2]).
With this post I'd like to start a discussion about the implementation and interfaces of this so the result can be reused in other contexts (e.g. for Snap). If you've got any suggestions and sources of inspiration I'm happy to hear them.
Best regards, Robin
Hi Robin, I know I already expressed this to you, but I'll state it for everyone: I'm very excited at the prospect of having a SPDY implementation. I'll admit to being a bit unknowledgeable of the inner workings of SPDY. My question is: what, if anything, needs to be modified in Warp to make this a possibility? There's already an experimental branch that adds direct tls support[1] to Warp, and the mechanism it uses is fairly generic, so it might be sufficient for providing SPDY support as well. The basic idea is to provide a general Connection type[2] that can be implemented by different backends. Also, that branch has bitrotted versus the 1.0 changes. I'll update it and have it ready for part of the 1.0 release. It would be great if whatever changes are necessary for SPDY were part of 1.0 as well. Michael [1] https://github.com/yesodweb/wai/tree/warp-tls [2] https://github.com/yesodweb/wai/blob/warp-tls/warp/Network/Wai/Handler/Warp....
On Mon, Jan 9, 2012 at 9:07 PM, Robin Brandt
Hello there,
I'm currently looking into implementing the SPDY [1] protocol based on Warp. I read in the archives that Daniel Sommermann wanted to start something similar for snap-server but I haven't seen any updates for some time. So if you've got a finished implementation somewhere in your drawer this would be a great time to publish it ;)
I briefly looked into implementing SPDY for Snap a while ago (i.e. I read
all the relevant papers and gave up). I came to the conclusion that given
my TODO list, the amount of effort required made the problem infeasible. I
would be really excited to see a SPDY implementation for any of the Haskell
web frameworks, because the hard problems to solve in a SPDY implementation
are not specific to any specific web implementation.
The biggest hurdle re: implementing SPDY is the TLS bits. The protocol is
documented (sort of), but all the magic numbers are listed as "TBD" in the
spec. I spent a good two hours trying to pick my way through the chromium
fork of OpenSSL (if you have preexisting expertise or lots of time and a
hard hat, good luck with that) before giving up and asking for help
internally at Google. It's been a while now, so the details are a little
fuzzy, but the numbers are all TBD because IANA/IETF/whoever wants them to
stay that way until the spec is finalized, and no, there aren't really any
other docs about implementing this protocol other than the proposed specs
and the source code. And oh yeah, this is in crypto code, so if you touch
the wrong thing the wrong way, you've exposed yourself to side-channel
attacks, or worse.
Between next protocol negotiation, TLS false start, TLS snap start, and the
SPDY multiplexing code itself (by far the easiest problem to overcome: it's
straightforward and non-archaeological), I concluded that implementing all
of this crap might take me a month or two if I were doing it full time at
my day job. As a "hobby-time" project? For me, intractable right now. It
would be a really fun and interesting project for someone with the time
though.
G
--
Gregory Collins
Hello Gregory,
first of all: thanks for summing up your previous encounter with SPDY.
On Tue, Jan 10, 2012 at 8:41 PM, Gregory Collins
The biggest hurdle re: implementing SPDY is the TLS bits.
I totally agree. From what I've read about the other experimental implementations of SPDY servers I've got the impression that implementing the TLS extensions (except next protocol negotiation) are at least not required at the moment. Of course it would be nice to benefit from the reduced TLS handshakes but it's not needed to start with. My idea was that this can be implemented afterwards once the specs for the extensions are final. Hopefully with some help from someone who's more into crypto code ;) Once we've got the basic framing layer running we could start working on the web application layer to see which changes are needed to support stuff like server pushes via SPDY. I haven't looked at the SPDY implementation of the upcoming firefox version yet so I don't know if my assumptions about the TLS bits are true but I will do so in the next days. Thanks again for your thoughts on this. Best regards, Robin
participants (3)
-
Gregory Collins -
Michael Snoyman -
Robin Brandt