add closenotify and large timeout to gateway

[whyrusleeping]

gateway requests that fail to resolve would cause goroutines to build up indefinitely.

License: MIT
Signed-off-by: Jeromy jeromyj@gmail.com

[jbenet]

Yep, LGTM.

Was thinking that we should have a LivenessContext that cancels if there hasn't been i/o for a while. (or of a certain rate) meaning that if a request is making forward progress, it continues. if it's not, it's killed after some timout. this will allow us to place "timeouts" on requests without hosing people with low bw/ high latency connections. I.e. if person is making fwd progress on a request that's taking an hour, the request should continue, but if the request has been totally stalled for 5m, it probably should not.

[whyrusleeping]

I'm looking at writing that right now, and to get it as efficient as i'd want it, i would need to fork the context lib. (otherwise i need one goroutine per extra context). They (as the go team likes to do) made some methods and interfaces private that would let users efficiently extend their code.

[jbenet]

:c pike!!!!.png

On Thu, Nov 19, 2015 at 10:08 PM Jeromy Johnson notifications@github.com
wrote:

I'm looking at writing that right now, and to get it as efficient as i'd
want it, i would need to fork the context lib. (otherwise i need one
goroutine per extra context). They (as the go team likes to do) made some
methods and interfaces private that would let users efficiently extend
their code.

—
Reply to this email directly or view it on GitHub
#1980 (comment).

[whyrusleeping]

I'm considering actually forking it, and making the relevant parts exported. It would allow for more easily exensible contexts for anyone who wants to interop with us (or use that lib)

[jbenet]

im fine with that

[whyrusleeping]

mmmm.... forking time 💃

[whyrusleeping]

merging, keepalive context stuff can come later.