resume the swarm and restart peer discovery on interested

[asapach]

based on discussion in #116

[jaruba]

Since making the changes to torrent-stream and peer-wire-swarm from the pull requests related to this issue, the same torrents that wore dropping (after a while) to 0 peers after all selected files have been downloaded, don't drop to 0 peers anymore.

I still think both these pull requests are necessary, but thought I should also mention this as it could be helpful information.

engine.amInterested becomes false and swarm.paused becomes true as they should after all selected files are downloaded, but the peers are not dropped anymore (even waited 40 mins), and I doubt I am of interest as a seeder for 6 peers for so long after downloading only 1 file of 156mb. (the same 6 peers I've downloaded the file from)

Could this be unrelated? Is there any reason why the peers wouldn't disconnect? (maybe they are seedboxes?)

But selecting a new file does do what it's supposed to. (discovers more peers / reconnects to old ones)

[jaruba]

Peers not disconnecting was unrelated, I checked more torrents in the meanwhile. There are some peers that always stay connected even when all others are disconnected.

It was just a coincidence that all 6 peers in that test didn't disconnect as they should.

[Miyou]

I'm having similar problems. After partially streaming a torrent and closing the read stream, the peers disconnect and are not reconnected once the createReadStream() function is called.
I managed to fix this by adding these lines to the engine.select() function:

discovery.restart();
swarm.reconnectAll();

However, when using peerflix-server, engine.select is called multiple times when starting up a stream and you might not want to run discovery.restart multiple times? So there probably is a better way to do this, but It works for me so far.

[jaruba]

@Miyou That is exactly what this pull request and this one: mafintosh/peer-wire-swarm#15 do.

They just need to be merged into the repos, and also this line should be removed from peerflix:
https://github.com/mafintosh/peerflix/blob/master/index.js#L197

It's been 20 days though, I have no idea why they haven't been merged yet.

[Miyou]

@jaruba Problem is wires are only reconnected if the swarm is currently paused when the engine becomes interested. When using peerflix-server the swarm isn't paused when you end a stream and so the wires don't reconnect when you start the stream back up again. So either run swarm.pause() in eos() or remove the check for the swarm being paused?

[jaruba]

@Miyou

swarm isn't paused when you end a stream

Are you referring to a situation in which you need to restart peer discovery in order to continue downloading the same file? ie: You have watched 10%, downloaded 30%, closed the laptop lid, went out for 10 hours, then came back and tried to continue watching? And that obviously might not work because all the peers you've used in your previous session have disconnected now?

[jaruba]

Truth be told, these 2 PR's are only a hackish solution to one very specific problem that I've been having since the very start of using peerflix. The problem that creates this scenario is not fully fixed and I have seen it create more issues such as the one I described above.

While investigating this I've seen a lot of behavior that I cannot fully explain.. The first problem is obviously with the trackers (the reason discovery.restart() needs to be used), the strange thing is that I don't think the trackers ever stop searching for new peers, I've seen new peers appear even after a very long time of downloading the same file. But discovery.restart() does naturally find a lot more new peers. This could although be the tracker's normal behavior.. Maybe restarting it is the only way to achieve this desired result or maybe the tracker isn't notified correctly of the progress of downloading so it does not send the correct peers efficiently.

The second problem is with the wire swarm, I don't think the peers should ever time out, and I don't think there is any reason to block them from ever reconnecting naturally again. I've seen peers stay connected for days when I've already finished downloading and other peers that I've downloaded from with the highest speed disconnect for no reason (then swarm.reconnectAll() finding them again). The current black list behavior has even killed the only peer I was actually downloading from on some poor health torrents.

We should not assume a normal behavior from peers as if they would only disconnect if they have nothing else to send. Users may restart their computers, pause seeding for a while, isp dropped, etc. I think the correct approach would be to attempt to reconnect back to older seeds periodically instead of disconnecting them and putting them on a black list. If this would be handled correctly swarm.reconnectAll() would not be needed anymore.

[Miyou]

@jaruba Yes, that is exactly what I mean. Peers disconnect after not streaming for an hour or so, so they need to be reconnected once the stream is created again.

[jaruba]

@Miyou It is not the only situation where this is needed, on poor health torrents you might loose a very important peer because he timed out but can become active again (without pausing streaming at all).

As yet another hackish solution for it, in Powder Player I save the timestamp of the last downloaded piece and check the timestamp on a 1 minute interval, if nothing was downloaded in 1 minute or more or there are very low peers it does:

discovery.restart();
swarm.reconnectAll();

This fixes both your scenario and also partially the one I just described (as peers may be lost but the torrent still download very slowly), but is just to ugly imo to push to torrent-stream, it needs a cleaner solution as I mentioned in the comment above.