Jump to content

Clarification of "partial seeds"


disco

Recommended Posts

Hi,

According to BEP 0021, "upload_only" goes outside of "m" dictionary but uTorrent and others put it inside "m" dictionary and are using it as an extended message.

BEP 0021 (http://bittorrent.org/beps/bep_0021.html) clearly states "upload_only" should not be inside "m"...

{'m': {'ut_metadata', 3}, 'upload_only': 1}

...but uTorrent (and others) have it there:

{e=1, ipv4=..., m={upload_only=3, ut_metadata=2, ut_pex=1}, metadata_size=..., p=..., reqq=255, v=µTorrent 1.8.2, yourip=...}

So, what am I missing here? Is there an updated BEP somewhere?

Link to comment
Share on other sites

Well, to be fair, I don't see anything in the BEP defining exactly where in the handshake message 'upload_only' is supposed to go. It gives an example where 'upload_only' is outside the 'm' dictionary, but it doesn't say anything about where it MUST go. It certainly needs clarification and/or updating.

I'll ask a dev.

Link to comment
Share on other sites

Indeed. I had no idea upload_only is a message when I read the BEP.

Before BEP gets updated, could you or someone else explain the correct usage of this message? Are there parameters other than 1 (i1e)? I suppose there isn't any response to it other than optional upload_only message to my client? I'm pretty much stuck at this point with outdated specs.

Thanks.

Link to comment
Share on other sites

Alright, alus basically said that the BEP is out of date. The 'upload_only' state can change at any given time, so it isn't really fit to be used as a standard piece of information sent in the basic part of the extended handshake (which seems to be used to define some elementary details about the client itself, not its current status). That's why µTorrent implements 'upload_only' in the extended message dictionary instead.

There should, AFAIK, be no particular way to interpret the 'upload_only' value other than that if it's mapped to 0, 'upload_only' is disabled. Any other value should be interpreted as "on" or "true" -- as long as it follows the extension protocol spec (anything in the 'm' dictionary should not have overlapping mapped IDs).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...