Clarify client announce behavior when joining both swarms of a hybrid…

[X-Coder264]

… torrent

As per the discussion in #87 (and partially in #100)

[the8472]

This is not a clarification but newly proposed behavior. And it is not in the compatibility spirit of BEP52.

Clients should be able to use existing torrents for pure v1, pure v2 and hybrid swarms, they can only do this by using the existing info_hash parameter which every tracker supports. Relying on a new info_hash_v2 parameter couldn't use existing infrastructure.

In practice, to be forward-compatible a client also must announce the new infohash on a hybrid torrent. The only wiggle room would be about whether and when it announces the old infohash.

Additional parameters can only serve as hint for bep52-aware trackers at best.

[arvidn]

yes, I agree. This should not be a MUST requirement. One way to achieve fewer announces in a backwards compatible way would be to also define a tracker response indicating that the tracker did also announce the peer against the v2 info-hash, so the peer knows it can omit the separate v2 announce.

But without knowing for sure that the info_hash_v2 was taken into account, it would have to also announce it as a separate request. Perhaps we could add wording to suggest using the same HTTP connection (relying on http keep-alive).

[arvidn]

come to think of it, if the same HTTP connection is used, it's not clear there is really that much value in saving a request. Most likely both requests would fit in a single TCP segment anyway, so from the network's point of view it may be unnecessary complexity to have an info_hash_v2 parameter

[X-Coder264]

We settled on (b) option from #87 and @arvidn suggested this further improvement regarding sending the info_hash_v2 parameter to reduce the number of requests. Since apparently it's not in the compatibility spirit of BEP 52 I've reverted this PR to just clarify the (b) option as it was originally discussed.

[arvidn]

It's not obvious to me that this additional wording is necessary. Isn't this implied?

[X-Coder264]

If it was implied then the reason for the discussion that took place in #87 wouldn't exist, no? Besides, stuff like that should always be explicit in documents such as this.

[arvidn]

If it was implied then the reason for the discussion that took place in #87 wouldn't exist, no?

I'm not sure what you mean. Are you saying that it's not implied?

Besides, stuff like that should always be explicit in documents such as this.

The risk with stating all consequences explicitly is that you get a lot of noise, and make the document longer, and have more opportunities for bugs, and there will always be something that's implied that's not stated explicitly.

Is this stated explicitly in the multi-tracker extension?

[X-Coder264]

I'm not sure what you mean. Are you saying that it's not implied?

Yes, I'm saying that it is not implied. One of the sentences in my original post in #87 is

It says that a client can join both swarms, but it doesn't specify the way how should the client announce its traffic to the tracker in such a case.

Following that sentence I've written the two possible options to which @the8472 said:

If you can settle on one and maybe rope in some tracker and client implementers into the discussion we can add that to spec or write an additional, informational BEP that documents ratio accounting common practices.

So this PR aims to do just that. Maybe the wording needs to be a bit better (I'm not a native English speaker) so any suggestions are welcome.

Is this stated explicitly in the multi-tracker extension?

IIRC, it isn't. But that is completely different (multi tracker vs multiple swarms) and it isn't used nearly as much (at least not by private trackers who are the most concerned about specifying the announce behavior when multiple swarms become a pretty frequent thing).

[arvidn]

But that is completely different (multi tracker vs multiple swarms)

good point.

Implementations supporting both formats which joined both swarms of a hybrid torrent
MUST announce by making two requests (one for each swarm/info_hash). For each request
the downloaded and uploaded parameters MUST contain the sum amount
that was respectively done in both swarms together.

I guess I was focusing on the first sentence, which I think is implied. Not the second though. What do you think of something like:

Implementations which join both swarms of a hybrid torrent MUST include the transfers from both swarms in the downloaded and uploaded counters sent in both tracker announces.

[X-Coder264]

Yes, the first part is implied so the focus of the PR is to specify the second part. Your wording sounds better to me so I'll update the PR tomorrow with it.