Протокол DHT | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translated in draft, editing and proof-reading required.
If you do not want to register an account, you can sign in with OpenID.
Protocol DHT | ||
Overview | ||
Each node has a globally unique identifier known as the "node ID." Node IDs are chosen at random from the same 160-bit space as BitTorrent infohashes [2]. A "distance metric" is used to compare two node IDs or a node ID and an infohash for "closeness." Nodes must maintain a routing table containing the contact information for a small number of other nodes. The routing table becomes more detailed as IDs get closer to the node's own ID. Nodes know about many other nodes in the DHT that have IDs that are "close" to their own but have only a handful of contacts with IDs that are very far away from their own. | Каждый узел имеет уникальный идентификатор, называемый «node ID». Этот идентификатор случайным образом выбирается из того же 160-битного диапазона значений, что и infohash используемый в BitTorrent протоколе. «Distance metric» (расстояние) используется для сравнения «node ID» двух узлов или «node ID» узла с «infohash» для определения их «близости». Узлам необходимо хранить таблицу маршрутизации, содержащую контактную информацию о небольшом количестве других узлов. Таблица маршрутизации постепенно наполняется идентификаторами, близкими к идентификатору данного узла. Узлам известно о множестве других узлов в DHT, идентификаторы которых «близки» к данному узлу, и лишь о нескольких «далёких». | |
In Kademlia, the distance metric is XOR and the result is interpreted as an unsigned integer. distance(A,B) = |A xor B| Smaller values are closer. | В Kademlia, дистанция рассчитывается при помощи XOR и результат интерпретируется как беззнаковое целое (unsigned integer). distance(A, B) = |A xor B| . Меньшие значения считаются более близкими. | |
When a node wants to find peers for a torrent, it uses the distance metric to compare the infohash of the torrent with the IDs of the nodes in its own routing table. It then contacts the nodes it knows about with IDs closest to the infohash and asks them for the contact information of peers currently downloading the torrent. If a contacted node knows about peers for the torrent, the peer contact information is returned with the response. Otherwise, the contacted node must respond with the contact information of the nodes in its routing table that are closest to the infohash of the torrent. The original node iteratively queries nodes that are closer to the target infohash until it cannot find any closer nodes. After the search is exhausted, the client then inserts the peer contact information for itself onto the responding nodes with IDs closest to the infohash of the torrent. | Когда узлу необходимо найти пиров для торрента, он использует «расстояния», сравнивая хеш торрента (infohash) с идентификаторами узлов («node ID») из своей таблицы маршрутизации. Затем он соединяется с известными ему узлами, идентификаторы которых более близки к хешу торрента, и запрашивает у них контактную информацию о пирах, участвующих в данный момент в файлообмене этого торрента. Если узлу, с которым установлена связь, известно о пирах для этого торрента, то в его ответе будет возвращена контактная информация о них. В противном случае, в своем ответе, узел должен вернуть контактную информацию о наиболее «близких» к хешу торрента узлах, из своей таблицы маршрутизации. Далее наш узел циклично опрашивает все более «близкие» к хешу торрента узлы, до тех пор пока не будут найдены все самые «близкие» узлы. После того, как ресурсы поиска исчерпаны, клиент рассылает свою контактную информацию всем ответившим пирам, идентификаторы которых наиболее «близки» к хешу торрента. | — не ясно скольким именно узлам отправляется запрос, одному? двум или еще большему количеству? раз речь идет о наиболее близких ID, то наверное запрос уходит одному узлу, с самым близким ID? если на вопрос будет ответ дальше, то надо сделать на это ссылку — KOHb Comment was deleted — Попробую объяснить работу своими словами. Пусть имеется клиенты А, B, C, которые хотят скачать некий файл с хешем H, но ничего не знают друг о друге. Пусть имеется клиент Z. Он ничего не знает о файле с хешем H, но, так уж выпало судьбой, что Z имеет ID наиболее близкий к хешу H. Клиент A начинает искать пиров качающих файл с хешем H и доходит до клиента Z. Z обламывает A, т.к. ничего не знает о файле H, но при этом Z запоминает ip и порт клиента A. Через некоторое время просыпается клиент B. Он тоже добирается до Z. И вот тут Z сообщает клиенту B о клиенте A. Z так же запоминает координаты клиента B. Когда до Z добирается клиент C, Z сообщает ему об A и B... — dr15x86 Comment was deleted |
The return value for a query for peers includes an opaque value known as the "token." For a node to announce that its controlling peer is downloading a torrent, it must present the token received from the same queried node in a recent query for peers. When a node attempts to "announce" a torrent, the queried node checks the token against the querying node's IP address. This is to prevent malicious hosts from signing up other hosts for torrents. Since the token is merely returned by the querying node to the same node it received the token from, the implementation is not defined. Tokens must be accepted for a reasonable amount of time after they have been distributed. The BitTorrent implementation uses the SHA1 hash of the IP address concatenated onto a secret that changes every five minutes and tokens up to ten minutes old are accepted. | Когда узел запрашивает информацию о пирах для торрента, в ответ ему также приходит секретное значение «token». Если наш узел впоследствии решит проинформировать узел, к которому обращался ранее, о том что «мы» участвуем в файлообмене по запрашиваемому торренту, наш узел должен будет вернуть обратно этот «token». В свою очередь узел который предоставил «token», проверяет его используя IP нашего узла. Это позволяет предотвратит регистрацию торрентов «на имя» других узлов. Время, в течении которого возвращенный «token» всё ещё будет считаться «валидным», настоящим руководством точно не регламентируется. Token'ы должны приниматься обратно лишь в течении некоторого приемлемого количества времени. Реализация в BitTorrent использует хеш SHA1 от IP адреса и некоторого секретного значения, которое изменяется каждые 5 минут; принимаются token’ы, которым не более 10 минут. | Comment was deleted |
— мне кажется, можно вставить куски перевода с Википедии http://ru.wikipedia.org/wiki/DHT#.D0.... — dr15x86
— там перевод для чайникок, почему собственноя и начал перевод технического текста тут — KOHb
— Зря вы не добавили «Содержание» и оформили часть текста как аннотацию. Кстати как сделать перевод этой аннотации? — Ruzzz