blocks|key|2003534|text|当我开始回答你的问题时，我没有意识到你问的是磁铁计划是如何工作的。我以为你想知道与bittorrent协议相关的部分是如何生成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2003535|2003536|磁石uri中列出的散列是在base32中编码的torrent的信息散列。info散列是torrent的bencoded块的sha1散列。|2003537|这个python+code演示了如何计算它。|offset|length|2003538|我写了一个(非常幼稚的)+C#实现来测试这一点，因为我手头没有一个本编码器，它符合客户端的期望。|2003539|static+string+CalculateInfoHash(string+path)
{
++++//+assumes+info+block+is+last+entry+in+dictionary
++++var+infokey+=+"e4:info";
++++var+offset+=+File.ReadAllText(path).IndexOf(infokey)+%2B+infokey.Length;
++++byte[]+fileHash+=+File.ReadAllBytes(path).Skip(offset).ToArray();
++++byte[]+bytes;
++++using+(SHA1+sha1+=+SHA1.Create())
++++++++bytes+=+sha1.ComputeHash(fileHash,+0,+fileHash.Length+-+1);+//+need+to+remove+last+'e'+to+compensate+for+bencoding
++++return+String.Join("",+bytes.Select(b+=>+b.ToString("X2")));
}|code-block|syntax|javascript|2003540|据我所知，这个散列不包括任何关于如何定位追踪器的信息，客户端需要通过其他方式找到它(提供的公告url+)。这就是在跟踪器上区分不同激流的原因。|2003541|与bittorrent协议相关的一切仍然围绕着跟踪器。它仍然是蜂群之间交流的主要手段。magnet方案并不是专门为bittorrent设计的。任何P2P协议都可以使用它作为另一种通信形式。Bittorrent客户端接受磁铁链接作为识别torrents的另一种方式，这样你就不再需要下载.torrent文件了。磁体uri仍然需要指定tracker以便定位它，以便客户端可以参与。它可以包含有关其他协议的信息，但与bittorrent协议无关。没有追踪器，bittorrent协议最终将无法工作。|style|CODE|2003542|entityMap|0|LINK|mutability|MUTABLE|url|http://osdir.com/ml/network.bit-torrent.general/2002-11/msg00023.html^0|0|0|0|2|B|0|0|0|0|0|4L|2|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|15|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|16|8|@]|9|@$G|17|H|18|1|19]]|A|$]]|$1|I|3|J|5|6|7|1A|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1B|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|1C|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1D|8|@$G|1E|H|1F|T|U]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|12]]]]

When I started answering your question, I didn't realize you were asking how the magnet scheme works. Just thought you wanted to know how the parts relevant to the bittorrent protocol were generated.

<hr>

The hash listed in the magnet uri is the torrent's info hash encoded in base32. The info hash is the sha1 hash of the bencoded info block of the torrent.

This <a href="http://osdir.com/ml/network.bit-torrent.general/2002-11/msg00023.html" rel="noreferrer">python code</a> demonstrates how it can be calculated.

I wrote a (very naive) C# implementation to test this out since I didn't have a bencoder on hand and it matches what is expected from the client.

<pre class="lang-c# prettyprint-override"><code>static string CalculateInfoHash(string path)
{
 // assumes info block is last entry in dictionary
 var infokey = "e4:info";
 var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
 byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
 byte[] bytes;
 using (SHA1 sha1 = SHA1.Create())
 bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
 return String.Join("", bytes.Select(b =&gt; b.ToString("X2")));
}
</code></pre>

As I understand it, this hash does not include any information on how to locate the tracker, the client needs to find this out through other means (the announce url provided). This is just what distinguishes one torrent from another on the tracker.

Everything related to the bittorrent protocol still revolves around the tracker. It is still the primary means of communication among the swarm. The magnet uri scheme was not designed specifically for use by bittorrent. It's used by any P2P protocols as an alternative form of communicating. Bittorrent clients adapted to accept magnet links as another way to identify torrents that way you don't need to download .torrent files anymore. The magnet uri still needs to specify the <code>tr</code>acker in order to locate it so the client may participate. It can contain information about other protocols but is irrelevant to the bittorrent protocol. The bittorrent protocol ultimately will not work without the trackers.

blocks|key|1789872|text|I+finally+found+specification.+For+the+first+time+google+didnt+help。(维基链接到bittorrent.com，这是主站点。我点击了developers链接，注意到右边的bittorrent.org选项卡，然后就很容易了。当你不知道它们是什么标签并且点击了很多次时，很难找到链接)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1789873|似乎所有的torrents都有一个对等网络。您可以从跟踪器中找到同级，并在会话之间保留这些同级。该网络允许您查找对等点和其他内容。我还没有读过它是如何与magnet+links一起使用的，但它似乎还没有定义一个新客户如何找到同行。也许有些是内置的，或者他们使用自己的家庭服务器或嵌入到客户端的已知跟踪器来获取网络中的第一个对等点。|1789874|entityMap|0|LINK|mutability|MUTABLE|url|http://www.bittorrent.org/beps/bep_0005.html#bittorrent-protocol-extension|1|http://www.bittorrent.org/beps/bep_0009.html^0|0|1V|0|0|24|C|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

<a href="http://www.bittorrent.org/beps/bep_0005.html#bittorrent-protocol-extension" rel="noreferrer">I finally found specification. For the first time google didnt help</a>. (wiki linked to bittorrent.com which is the main site. I Clicked the developers link, notice the bittorrent.org tab on the right then it was easy from there. Its hard finding links when you have no idea what they are labeled and many clicks away).

It seems like all torrents have a network of peers. You find peers from trackers and you keep them between sessions. The network allows you to find peers and other things. I havent read how its used with <a href="http://www.bittorrent.org/beps/bep_0009.html" rel="noreferrer">magnet links</a> but it seems like it is undefined how a fresh client find peers. Perhaps some is baked in, or they use their home server or known trackers embeded into the client to get the first peer in the network.

blocks|key|2003636|text|对等点列表可能是从升级客户端的torrent中填充的(例如，utorrent的torrent就是升级它的torrent)。只要每个人都在使用相同的客户端，这应该是很好的，因为您别无选择，只能共享升级。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2003637|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

the list of peers are probably populated from the torrent that upgrades the client (e.g. there's a torrent for utorrent that upgrades it). as long as everyone's using the same client, it should be good because you have no choice but to share the upgrade.

blocks|key|1790024|text|我自己也对同样的问题感到好奇。阅读传输代码时，我在libtrnasmission/tr-dht.c中发现了以下内容|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1790025|3248:+++++bootstrap_from_name(+"dht.transmissionbt.com",+6881,
+++++++++++++++++++++++++++++++bootstrap_af(session)+);|code-block|syntax|javascript|1790026|它尝试了6次，等待了40(!)两次尝试之间的秒数。我猜你可以通过删除配置文件(unix上的~/.config/transmission)，并阻止所有与dht.transmissionbt.com的通信来测试它，看看会发生什么(至少等待240秒)。|1790027|因此，客户端似乎一开始就有一个内置的引导程序节点。当然，一旦它进入网络，它就不再需要引导节点了。|1790028|entityMap^0|P|O|0|0|19|M|23|M|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|Z|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|P|$]]

I was curious by the same question myself. Reading the code for transmission, I found the following in <code>libtrnasmission/tr-dht.c</code>:

<pre><code>3248: bootstrap_from_name( "dht.transmissionbt.com", 6881,
 bootstrap_af(session) );
</code></pre>

It tries that 6 times, waiting 40(!) seconds between tries. I guess you can test it by deleting the config files (<code>~/.config/transmission</code> on unix), and blocking all communication to <code>dht.transmissionbt.com</code>, and see what happens (wait 240 seconds at least).

So it appears the client has a bootstrap node built in to start with. Of course, once it has gotten into the network, it doesn't need that bootstrap node anymore.

For the first time I used a <a href="http://en.wikipedia.org/wiki/Magnet_URI_scheme" rel="noreferrer">magnet link</a>. Curious about how it works, I looked up the specs and didn't find any answers. The wiki says <code>xt</code> means "exact topic" and is followed by the format (<code>btih</code> in this case) with a SHA1 hash. I saw base32 mentioned, knowing it's 5 bits per character and 32 characters, I found it holds exactly 160bits, which is exactly the size of the SHA1.

There's no room for an IP address or anything, it's just a SHA1. So how does the BitTorrent client find the actual file? I turned on URL Snooper to see if it visits a page (using TCP) or does a lookup or the like, but nothing happened. I have no idea how the client finds peers. How does this work?

Also, what is the hash of? Is it a hash of an array of all the file hashes together? Maybe it's a hash of the actual torrent file required (stripping certain information)?

<hr>

In a VM, I tried a magnet link with uTorrent (which was freshly installed) and it managed to find peers. Where did the first peer come from? It was fresh and there were no other torrents.

How do BitTorrent magnet links work?

服务器

虚拟机

这是我第一次使用。出于对它的工作原理的好奇，我查看了规格，但没有找到任何答案。维基说，xt的意思是“确切的主题”，后面跟着格式(在本例中是btih)和一个SHA1散列。我看到提到的base32，知道它是每个字符5位和32个字符，我发现它恰好包含160位，这正是SHA1的大小。没有IP地址或任何东西的空间，它只是一个SH...

问BitTorrent磁铁链接是如何工作的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问BitTorrent磁铁链接是如何工作的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问BitTorrent磁铁链接是如何工作的？
EN