Consider adding a "free rider" and "findpeers" options

[Ayms]

Free rider: disable storing pieces (only mem[index] is used in memory) and disable sending 'have' to other peers, other peers can still see you of course but you minimize your participation to a torrent, the rational is for a project like Peersm where other peers are relaying data for you and then should not keep what they are relaying and neither advertise themselves. Small changes that I can provide if there is an interest.

Findpeer: there is a TODO comment in the code, I don't know exactly why the 10000 value was chosen but it causes in my case an average delay of 2mn before things start, maybe it could become an option (in the meantime routing tables are added???)

[asapach]

Findpeer: there's an intermediate solution in #22

[Ayms]

Thanks, we use 100 and it seems to work well.

[BastienClement]

Since I'm currently working on unchoking management, it seems like the right time to discuss a free-rider option. Basically, by not unchoking peers, we will never upload anything (and testing proves this to be viable).

But this kind of behaviour is bad for the torrent's ecosystem. Since not following the "rarest-first" logic for piece selection is already not optimal, I would be against adding a simple opts.freerider option to encourage even less optimal behaviour.

Of course everyone is free to edit the code itself and change this.

[asapach]

It would be best if torrent-stream would allow to hook into the algorithm and implement your own strategy.

I agree about the ecosystem and think that one of the main criteria we need to consider is: will a swarm consisting entirely of torrent-stream peers survive? Will it be able to maintain a healthy balance?

[Ayms]

Even if the free rider option is not really fair, there is a rationale for this, you can read for example http://lists.zooko.com/pipermail/p2p-hackers/2014-May/003262.html, that's specific of course, maybe nobody else is interested.

Is the torrent-stream algorithm documented somewhere? I am still wondering about #30 , whether I am doing something wrong or just the bittorrent algorithm (despite of rarest first & co), and torrent-stream, does not know how to handle this.

[Ayms]

Do you want to go for the freerider option or not?

If not I have to maintain a specific version of torrent-stream which makes more difficult to follow the changes and contribute here (or possibly webtorrent), moreover that torrent-stream in its initial version was a kind of free rider but is becoming less and less due to the enhancements.

If yes, I can provide the simple changes or commit something (first option preferred)

In essence, talking about streaming only, which is supposed to be ephemeral, it's not unlogical at all that the torrent-stream client behaves like a freerider, so it's not unlogical to have at least the option.

This does not prevent other torrent-stream clients to behave normally so a torrent-stream swarm could survive.

[mafintosh]

@galedric @asapach any input on o/

[asapach]

@mafintosh, I don't think the freerider option should be available out of the box, but it would be good to have an extensibility point for a consumer to implement one.

[Ayms]

I just released https://github.com/Ayms/torrent-live

You can seek for 'freerider' for the modificiations, as you can see they are trivial (and sometimes a bit abrupt)

Not sure how it's possible for a consumer to implement one without hacking into the functions (ie overridding dht._onquery, things like this), I don't like it

Maybe not an option avalaible to everybody, but an option in the code then.

[dcerisano]

@Ayms The peer wire protocol has a Give-and-Take criterion (GT criterion) which is designed to discourage freeriders. Examples are "tit-for-tat" and the more modern "give-to-get" criteria.

[Ayms]

There is the theory and the practice, the bittorrent protocol does nothing to forbid freeriding, worse, torrent-live for example is not only not sharing but just does not respond to anything with the complete freerider option which is the default, why it is the default is explained in torrent-live repo or torrent-live

And this is working very well and why this is working is explained in the above links.

To understand maybe better the intent you can take a look at Monitoring and blocking the bittorrent monitoring spies

Complete freeriding is indeed a deviant behavior, but everybody knows that everybody is simply freeriding (ie not sharing after they get out of the swarm), and other deviant behaviors are vpn peers, or monitors, or popcorn stuff, etc

Now, should it be added to torrent-stream, I don't know, but I have made quite a lot of modifications since the initial post.

[dcerisano]

AFAIK, an upload rate of zero kills torrent downloads. Even the most rate limited bittorrent client will allow a couple of Kbps to keep the peer alive. Peers that allow true freeriding constitute a separate protocol. Please understand the GT enabled peers will simply share among themselves exclusively - that is the whole point.

[Ayms]

Yes, I did not say that freeriding was good (and morever total freeriding like torrent-live), it is explained in the repo why it is currently the default.

But I don't get very well what's your point regarding this issue, what do you propose here?

[gordonperlin]

What about "peers" that serve freeriders?

[dcerisano]

Note that "Taker" means a node that will choke non-Givers (freeriders are actually T compliant since they choke all requests). Current peer discovery still allows for some service to freeriders but is improving.

The vast majority of P2P clients have elected GT default settings so does torrent-stream, and most users never change them.

As for Bittorrent, it chokes freeriders - so does torrent-stream.
https://en.wikipedia.org/wiki/Tit_for_tat#Peer-to-peer_file_sharing

[Ayms]

What bittorrent clients use this from your standpoint (uTorrent?)

I have not studied this, but in practice totally freeriding (ie even not answering to anything) works very well, once torrent-live reaches the closest nodes, based on some criteria it chooses 20 peers in the swarm and download from them. Some peers apparently get pissed off that torrent-live's peer is not cooperating and disconnect, then torrent-live switches to another one, after some time torrent-live's swarm stabilizes and oscillates around 20 peers.

This works very well (even with small swarms), so if the most used bittorrent clients are implementing the anti freeriders features, it seems that this just does not work, again I did not check, but as far as I know popocorn time is freeriding too, I don't know to what extent.

[dcerisano]

Could you provide supporting data?

• Please use the same file for each comparison and post time to download entire file in seconds.
• Please use a traffic shaper to cap down/up link speed.

thx

Comparison of streaming Peer vs streaming Freerider download times
for various files with various availability.

Network:  1.0 Megabytes per second download cap, 100 Kilobytes per second upload cap.

Size     Resolution    Seeders    Leechers     Peer (seconds)     Freerider (seconds)
800 MB      720p       ~100        ~50      
800 MB      720p       ~1000       ~500    
800 MB      720p       ~10000      ~5000   
800 MB      720p       ~50         ~100      
800 MB      720p       ~500        ~1000     
800 MB      720p       ~5000       ~10000    
1.5 GB     1080p       ~100        ~50
1.5 GB     1080p       ~1000       ~500
1.5 GB     1080p       ~10000      ~5000
1.5 GB     1080p       ~50         ~100
1.5 GB     1080p       ~500        ~1000
1.5 GB     1080p       ~5000       ~10000

• Availability is the ratio of seeders to leechers in your testing environment.

[Ayms]

You did not answer the question (what bittorrent clients are supposed to implement the anti freeriders features?) and I don't really get your test case, you can try torrent-live if you want to get some statistics.

[dcerisano]

You must support your performance claim. It is not my claim to support.
Surely your performance claim is based on the evidence specifically called for, and not just trolling?

Choking leeches is the basis of the peer wire protocol and all peers must do it (even your leeching clone of torrent-stream does it) as previously answered.

Surely your proposed contributions are constructive additions, and not thoughtless hacks?

[Ayms]

Obviously you are just a complete idiot trolling this thread in order to try understanding what torrent-live does

[asapach]

Locking this issue to prevent further flame wars.