Lag on catReadableStream (possibly other stream methods as well)

[lifeBCE]

• Version:
  0.33.1

• Platform:
  Mac OS X 10.12.6
  Chrome: Version 70.0.3538.77 (Official Build) (64-bit)
  FireFox: 63.0.1 (64-bit)

• Subsystem:
  ?

Type:

Bug (maybe Enhancement?)

Severity:

High

Description:

When using js-ipfs as a client in a browser, executing node.files.catReadableStream starts the blocks streaming into the websocket connections immediately but it takes sometimes over 10 seconds before the stream triggers the first data event.

Basically, more than 10 seconds of lag between these two lines:

    this.stream = this.state.node.files.catReadableStream(hash)
    this.stream.on('data', (block) => {});

But as soon as the first line is executed, I see blocks coming across the websocket instantly. Is this by design or is there a problem here?

Steps to reproduce the error:

1. Load up js-ipfs package in browser session.
2. Start a browser node
3. Once peers are connected, call catReadableStream on any hash (larger files work better as the process is really over before you know what happened on smaller files)

[alanshaw]

Closing this as a duplicate of #1709 - let me know if that doesn't sound right @lifeBCE

[lifeBCE]

@alanshaw I don't think these are the same but could be the same cause? #1709 sounds like it is taking 8 seconds to transfer a local file from one local peer to another and does not seem to have anything to do with the websocket functionality.

My issue is that the embedded browser node from js-ipfs is pulling the blocks from the bootstrap node over the websocket connection but the data event is not fired on the stream for like 10+ seconds while the blocks are coming through the stream instantly.

I was thinking at first that it could be blocks that are out of order coming in first and the lag is due to waiting for the initial blocks to construct the beginning of the stream but then remembered reading something in the white paper for IPFS that said that beginning blocks are sent first to avoid such an issue?

[alanshaw]

@lifeBCE is the first data event being triggered after the full response is received?

[lifeBCE]

@alanshaw It does eventually get triggered but it doesn't seem to be after the full download completes. It seems to be about the same 8-10 seconds regardless of the size of the file. I have tested this against small 30 second video clips as well as an over 2 hour video and the lag time is the same for both and any length in between.

I have added some additional logic to my service to pre-load the first 5 MB of the next video in order to combat this lag a bit and that does seem to help. Pre-loaded videos show about only a 2 second lag before the data event is fired.

[lifeBCE]

Did some initial digging.

According to pull-defer docs (https://github.com/pull-stream/pull-defer) when using a deferred source stream, the stream is started when resolve is called as it is here.

js-ipfs/src/core/components/files-regular.js

Line 249 in ac5fa8e

d.resolve(content)

//nothing will happen until deferred.resolve(stream) is called.
deferred.resolve(input)

The logic above is called from the public function definition here:

js-ipfs/src/core/components/files-regular.js

Line 382 in ac5fa8e

catReadableStream: (ipfsPath, options) => toStream.source(_catPullStream(ipfsPath, options)),

I started honing in on toStream as a potential culprit and this is where my investigation has stopped. The docs on pull-stream-to-stream are a bit vague to say the least. https://github.com/pull-stream/pull-stream-to-stream

Doing some A/B testing (maybe benchmarking) between catPullStream and catReadableStream may give some insight as both call the internal _catPullStream function but only catReadableStream calls toStream.

    catReadableStream: (ipfsPath, options) => toStream.source(_catPullStream(ipfsPath, options)),

    catPullStream: (ipfsPath, options) => _catPullStream(ipfsPath, options),

This is where the data event is emitted (in the pull-stream-to-stream logic). This is the trigger for the stream that lags for me in my code.
https://github.com/pull-stream/pull-stream-to-stream/blob/master/index.js#L101

Looks like something is lagging when calling the drain function.

[alanshaw]

@lifeBCE a few things I think you can check/do:

1. can you confirm that this behaviour does not happen when you use catPullStream?
2. if you pipe the stream to a writable does it still take 10s for the frist write?
3. a runnable example of this problem would help considerably...