Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wire contexts into bitswap requests more deeply #1986

Closed
wants to merge 335 commits into from

Conversation

whyrusleeping
Copy link
Member

This should address the issue of wantlist entries persisting in the wantlist and not being cancelled when things like 'ipfs get' are killed early

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

req := &blockRequest{
keys: keys,
ctx: ctx,
// NB: Optimization. Assumes that providers of key[0] are likely to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought broadcasting every blocks independently is too granular considering the bandwidth cost & rtt. This reduces dup subsequent blocks download as well (except that within the first 10s, there will be duplicated download chains)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be separated out into another PR.

@rht
Copy link
Contributor

rht commented Nov 21, 2015

Tested, the result is wantlist doesn't get cleared after client exit.

  • ipfs daemon &
  • ipfs bitswap stat no wantlist
  • ipfs get $sintel
  • ipfs bitswap stat in another terminal, contains the hash
  • C-c ipfs get
  • ipfs bitswap stat wantlist contains the hash
  • ipfs bitswap stat >10s later wantlist still contains the hash

@rht
Copy link
Contributor

rht commented Nov 22, 2015

I tried catching the ctx.Done() to print the message, inside the Run phase of ipfs get (rht@8d1ea86).

The msg only gets printed when the daemon exits, but not when the client exits.
This would mean any pending request by a client won't ever be canceled?

@whyrusleeping
Copy link
Member Author

@rht, thanks for investigating. I dont think the context from the api request is being passed down to the getblocks requst properly. I need to look at that wiring a little more closely.

@whyrusleeping
Copy link
Member Author

it looks like closenotify isnt working for some reason... not sure why

@rht
Copy link
Contributor

rht commented Nov 22, 2015

Not sure the reason with why another transport is created just to cancel the client request here.

When I replaced it with the transport created previously, I was able to C-c the client once. Currently it has to be done twice. Is this a bug or feature?

@rht
Copy link
Contributor

rht commented Nov 22, 2015

test: I put a 1s timeout on the http handler that auto-cancel the connection. The wantlist still doesn't get gc-ed.

@whyrusleeping
Copy link
Member Author

this is waiting until we sort out the CloseNotify nonsense.

@rht
Copy link
Contributor

rht commented Nov 23, 2015

I tried simulating the closenotify, but in this PR, the wantlist still doesn't get gc-ed.
It does, however, in #1995.

@jbenet
Copy link
Member

jbenet commented Nov 30, 2015

would be awesome to get this figured out-- am sure lots of traffic happens because of these lingering ctxs

RichardLitt and others added 10 commits January 29, 2016 16:51
License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
Added quotes around block put command
License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
License: MIT
Signed-off-by: rht <rhtbot@gmail.com>
Also fixes some grammar in pings.

See #2265 (comment)

License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
hackergrrl and others added 24 commits February 29, 2016 16:05
License: MIT
Signed-off-by: Stephen Whitmore <noffle@ipfs.io>
License: MIT
Signed-off-by: Stephen Whitmore <noffle@ipfs.io>
License: MIT
Signed-off-by: Stephen Whitmore <noffle@ipfs.io>
License: MIT
Signed-off-by: Stephen Whitmore <noffle@ipfs.io>
Prevents 'ipfs name publish' when /ipns is mounted.
makes 'ipfs files write' usage docs clearer
It is not useful. See ipfs-inactive/http-api-spec#41 (comment)

License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
See ipfs-inactive/http-api-spec#41 (comment)

License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
Change language for files read slightly
Added an `as` to ensure good English
Makes install from source instructions clearer.
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
assert that you must build from inside your gopath
My bad. Introduced in #2366

License: MIT
Signed-off-by: Richard Littauer <richard.littauer@gmail.com>
License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>
@whyrusleeping whyrusleeping deleted the fix/bitswap-ctx-wire branch March 3, 2016 06:37
@whyrusleeping whyrusleeping restored the fix/bitswap-ctx-wire branch March 3, 2016 06:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants