SPDY/3

[Keith Rarick]

I'm working on hooking up the existing spdy package in go.net
to net/http. After talking briefly with Brad I'm about ready to
send a small "hello world" CL for go.net/spdy. If this goes well
I plan to follow up with many more incremental additions until
we support all features of spdy.

Rough strategy: use http.Server.TLSNextProto as it was intended.
Internally, each spdy session will funnel all incoming and outgoing
frames through one goroutine, which will track the state of all its
streams and enforce the spdy framing layer rules (e.g. valid stream
ids, flow control).

I'm happy to discuss this more here or go ahead and send the
change for initial review if it sounds reasonable.

Some things I'm unsure of:

- How much should ultimately be exported?

We might think of spdy in (at least) three layers: the framing
format already provided by go.net/spdy, the framing layer
communication rules (e.g. multiplexing, flow control), and
the http layer.

I can imagine some people wanting to use each of those
layers, though I expect the vast majority to use only the
high-level net/http hooks.

So I'm not sure about which symbols to make public.

- Split into multiple packages?

Should there be a go.net/spdy/http, or should everything be
lumped in together? Something else?

- It would be great to reuse more from net/http.
e.g. sniff buffering, multipart forms

A great deal of logic in net/http is specific to http's wire
format (for example, looking through the read buffer to find
the end of chunked encoding for trailer purposes), and I'm
grateful to leave it behind. But buffering part of the response
for sniffing, cleaning up multipart forms temp files, etc could
potentially be shared. Perhaps by exporting a ResponseWriter
wrapper for each one? Not sure if this is too much trouble;
I'm also ok with copying those things over, though of course
keeping up with bug fixes and enhancements will be not fun.

- How best to hook in requests to net/http?

Is there a client-side equivalent of http.Server.TLSNextProto,
so users can make a single call and get either spdy or plain
http, depending on what the remote server advertises?
Will it be possible to share net/http's connection pool?

[Mikio Hara]

On Sat, May 11, 2013 at 12:54 PM, Keith Rarick <k...@xph.us> wrote:

> Rough strategy: use http.Server.TLSNextProto as it was intended.
> Internally, each spdy session will funnel all incoming and outgoing
> frames through one goroutine, which will track the state of all its
> streams and enforce the spdy framing layer rules (e.g. valid stream
> ids, flow control).

It sounds good to me. I'm a bit curious how could you provide traffic
coloring, metering and queue strategy API but those are details.

> I'm happy to discuss this more here or go ahead and send the
> change for initial review if it sounds reasonable.

I'm fine either but perhaps rough API sketch might be helpful to
understand your design.

> - How much should ultimately be exported?

I personally think go.net/spdy should focus on SPDY session, stream
control and layering setup, teardown stuff.

> - Split into multiple packages?

Single package might be better because spdy package will stay
just in between net/http and crypto/tls or net.

> - It would be great to reuse more from net/http.
> e.g. sniff buffering, multipart forms

Let's steal and hold the code from net/http at first.

> - How best to hook in requests to net/http?

Seems like intermediary side support would be required but
not sure for client side.

[Keith Rarick]

On Wed, May 15, 2013 at 6:53 AM, Mikio Hara <mikioh...@gmail.com> wrote:
> It sounds good to me. I'm a bit curious how could you provide traffic
> coloring, metering and queue strategy API but those are details.

I'm not sure what you mean by coloring and metering. Those words
don't appear on
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
(except in reference to "file progress meters", outside the context
of spdy itself).

If, by queue strategy, you're referring to the stream priority field,
then for now I plan to ignore it. We can talk about how to either
expose that field to the user or make use of it internally in the
spdy package (or both).

[Mikio Hara]

On Thu, May 16, 2013 at 3:02 AM, Keith Rarick <k...@xph.us> wrote:

> I'm not sure what you mean by coloring and metering. Those words
> don't appear on
> http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
> (except in reference to "file progress meters", outside the context
> of spdy itself).

Sorry for the junk words, I mean,

> If, by queue strategy, you're referring to the stream priority field,
> then for now I plan to ignore it.

yup, above story; how could we map the http application intent to
a spdy stream, then accomodate multiple spdy streams to a spdy
session and so on.

> We can talk about how to either
> expose that field to the user or make use of it internally in the
> spdy package (or both).

Yup, but the big customer of go.net/spdy is net/http; it's a part of
stdlib and for now pretty hard to do repiping something especially
btw packages out of stdlib. Probably we should embed something
like hidden secret knobs to net/http or net eventually.

Thanks for explaining it.

[Brad Fitzpatrick]

I've talked to Keith about this.

I think we have the only hook we need in net/http.

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[far...@gmail.com]

Hi Keith, I'm playing with golang http and SPDY these days and have problem dealing with NPN.

Could you please explain what http.Server.TLSNextProto works?

Please see my other post for more details: http://stackoverflow.com/questions/18953186/what-is-the-proper-way-to-handle-tlsnextproto-in-golang-net-http

[Kevin Yuan]

OK. Got it. The certificate issue. Sorry for bothering.

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/hYNU9qAeCD4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+...@googlegroups.com.

[shka...@gmail.com]

Hi,

Is there a tutorial available on how to use this package with net/http?

Thanks,

Serge

[Keith Rarick]

There's no tutorial, but the package is documented.
You can browse at http://godoc.org/github.com/kr/spdy.

Note this package is still incomplete. It has no connection
pool. The best you can do right now is to dial your own
net.Conn, make a spdy.Conn, then use it as an http
RoundTripper.

Running a server is easier. Make a spdy.Server and call
ListenAndServeTLS.