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

Connection reuse failure when go-ipfs node called from Swift API client. #3767

Open
NeoTeo opened this issue Mar 8, 2017 · 8 comments
Open
Labels
topic/api Topic api

Comments

@NeoTeo
Copy link

NeoTeo commented Mar 8, 2017

Version information:

go-ipfs version: 0.4.6-dev-
Repo version: 5
System version: amd64/darwin
Golang version: go1.7

Type:

Bug

Priority:

P4

Description:

On @whyrusleeping’s suggestion I’m opening this issue which may involve the go-ipfs node not dealing properly with connection reuse.

The problem manifests as an X-Stream-Error response and a trailer with the error X-Stream-Error: multipart: Part Read: http: invalid Read on closed Body. The full exchange is shown in the following gist (ascii and hex dump).
The exchange is between the swift-ipfs-api and a localhost go-ipfs node.

The standard Cocoa frameworks recommended for URL connections do not allow for setting the http header field connection: close (see section on reserved HTTP Headers here) which means they are sent with connection: keep-alive. This (probably?) causes the ipfs node to reuse the connection and not always succeeding (sometimes it works, sometimes it partially works and other times it just fails).

The issue is whether the ipfs node is/should be able to properly handle connection reuse or whether Cocoa (mac & iOS) API clients need to force a connection: close on the headers by using a more low-level approach.

let me know if you need any more info.

:) Teo

@whyrusleeping whyrusleeping added this to the Ipfs 0.4.8 milestone Mar 12, 2017
@whyrusleeping whyrusleeping added the topic/api Topic api label Mar 12, 2017
@whyrusleeping
Copy link
Member

I tried a small experiment with a bunch of block get calls with connection reuse on and it appeared to work.

I will have to run some experiments with running add calls and see how that goes.

@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.9, Ipfs 0.4.8 Mar 24, 2017
@NeoTeo
Copy link
Author

NeoTeo commented Mar 24, 2017

On 0.4.6?

@Kubuxu
Copy link
Member

Kubuxu commented Apr 17, 2017

@NeoTeo any update on this?

@NeoTeo
Copy link
Author

NeoTeo commented Apr 17, 2017

@Kubuxu Not from me. I got the impression @whyrusleeping was going to run some add experiments and that the fix, if any, would be in 0.4.9. It wasn't completely clear which ipfs version the block get calls seemed to work ok with.

@whyrusleeping
Copy link
Member

Yeah, i still havent done that :/

@whyrusleeping
Copy link
Member

@NeoTeo Havent done this with ipfs add yet (its harder to have a scenario where this is needed). But I did do it with ipfs dag put (which also uses multipart uploads) and everything seemed to work fine. These tests were run on ipfs 0.4.8

@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.10, Ipfs 0.4.9 May 8, 2017
@magik6k magik6k modified the milestones: Ipfs 0.4.10, Ipfs 0.4.11 Jul 28, 2017
@whyrusleeping
Copy link
Member

@NeoTeo Do you still encounter this issue? I've been using connection reuse on quite a few different things now and havent encountered any errors.

If you still have the problem, could you post a code snippet or test that reproduces it?

@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.12, Ipfs 0.4.11 Sep 2, 2017
@NeoTeo
Copy link
Author

NeoTeo commented Sep 2, 2017

@whyrusleeping I've been too swamped to get back to testing it but at this point, with your successful reuse, I'd assume it's my error somewhere. I'll let you know if I come up with a reproducible case :)

@Kubuxu Kubuxu modified the milestones: Ipfs 0.4.12, go-ipfs 0.4.13 Nov 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/api Topic api
Projects
None yet
Development

No branches or pull requests

4 participants