Является ли hashinfo эквивалентом идентификатора узла в Mainline DHT?

Как вы структурируете свои данные внутри, зависит от вас. Все, что ему нужно сделать, это выполнить контракт спецификации. В принципе можно связать торренты с ведрами на основе расстояния xor — например. по причинам учета ресурсов, но в большинстве реализаций таблица маршрутизации и хранилище разделены.

Основная таблица маршрутизации содержит только узлы, структурные элементы самого наложения DHT. С другой стороны, торренты не являются частью оверлея. Это данные, хранящиеся поверх оверлея, абстракции хеш-таблицы. Отсюда и название — распределенная хэш-таблица. т.е. они существуют на разных уровнях абстракции.

Структура данных k-buckets — это деталь реализации протокола Bit-Torrent, поэтому одноранговые узлы достаточно быстро отвечают на FIND_PEERS и FIND_VALUE.

Что я делаю в своей реализации kademlia, так это сохраняю таблицу маршрутизации в словаре Python и вычисляю ближайшие одноранговые узлы менее 5 секунд по умолчанию, что является тайм-аутом, который я использую для ожидания ответа UDP. Для этого мне нужно, чтобы таблица маршрутизации не превышала 1 000 000 записей.

Как я уже сказал выше, таблица маршрутизации — это простой питон dict, который отображает peerid в (address, port).

В таблице маршрутизации хранятся одноранговые узлы, а не значения, т.е. не infohash адреса.

Когда я получаю сообщение FIND_PEERS, программа отвечает следующим кодом:

async def peers(self, address, uid):
    """Remote procedure that returns peers that are near UID"""
    log.debug("[%r] find peers uid=%r from %r", self._uid, uid, address)
    # XXX: if this takes more than 5 seconds (see RPCProtocol) it
    # will timeout in the other side.
    uids = nearest(self._replication, self._peers.keys(), uid)
    out = [self._peers[x] for x in uids]
    return out

Когда я получаю сообщение FIND_VALUE, программа отвечает следующим кодом:

async def value(self, address, key):
    """Remote procedure that returns the associated value or peers that
    are near KEY"""
    log.debug("[%r] value key=%r from %r", self._uid, key, address)
    out = await lookup(key)
    if out is None:
        # value is not found, reply with peers that are near KEY
        out = nearest(self._replication, self._peers.keys(), uid)
        return (b"PEERS", out)
    else:
        return (b"VALUE", out)

Вот определение nearest:

def nearest(k, peers, uid):
    """Return K nearest to to UID peers in PEERS according to XOR"""
    # XXX: It only works with len(peers) < 10^6 more than that count
    # of peers and the time it takes to compute the nearest peers will
    # timeout after 5 seconds on the other side. See RPCProtocol and
    # Peer.peers.
    return nsmallest(k, peers, key=functools.partial(operator.xor, uid))

То есть он сортирует peers в соответствии с их peerid и возвращает наименьшее k. nsmallest должен быть оптимизированной версией sort(peers, key=functools.partial(operator.xor, uid))[:k], где uid — это peerid или infohash (соответственно FIND_PEERS и FIND_VALUE).

Теперь вернемся к вашему вопросу (ам):

Is hashinfo equivalent to peer ID in Mainline DHT?

hashinfo — это хеш-то, что является хешем того же типа, что и peerid, т.е. это ключи возможно в таблице маршрутизации. То есть торрент-файлы связаны с хешем, пиры связаны с таким же хэшем, который называется peerid. И сверстники имеют «право собственности» на ключи, которые находятся рядом с их peerid. НО hashinfo не хранятся в таблице маршрутизации или k-buckets, если хотите. hashinfo хранятся в другом сопоставлении, которое связывает hashinfo хеш со своими значениями.

I am asking because this is not just implementation nuance. Because "k" is normally 20 or some other integer in all clients. So if I would use k-buckets to store torrent files as full-right members, I would have less space to store real peers data.

Здесь есть неправильное понимание того же, что я пытаюсь объяснить выше. hashinfo — ключи в словаре хранения. Принимая во внимание, что peerid — это ключи в таблице маршрутизации, также известные как. структура данных k-сегментов. Они оба имеют одинаковый формат, потому что именно так работает алгоритм маршрутизации kademlia. Вы должны иметь возможность сравнивать hashinfo с peerid с xor, чтобы иметь возможность сказать, какие одноранговые узлы «владеют» какой hashinfo ценностью.

Как вы можете видеть во втором фрагменте кода, когда другой одноранговый узел запрашивает значение, связанное с хешем, он вызывает lookup(key), что-то вроде storage.get(key), за исключением того, что в моем случае код сохраняет значения в базе данных.

Возможно, существует неправильное понимание того факта, что k-buckets используются для хранения информации DHT-маршрутизация. И этот торрент-протокол более того использует DHT для хранения информации поток маршрутизация.

Что бы это ни стоило, файл peer.py qadom — это место, где я реализую DHT, вдохновленный kademlia (за исключением того, что я использую 256-битный хеш и отказываюсь от параметров alpha и k и использую один параметр REPLICATION). Код работает большую часть времени проверьте тесты.

Кроме того, есть еще один проект, который меня вдохновил, называется просто кадемлия, который (пытается?) реализует k-buckets.

Насколько я понимаю, маршрутизация торрента DHT выглядит как функции qadom bag, за исключением того, что принимающий узел должен аутентифицировать объявление, тогда как в qadom пакеты являются бесплатными для всех.

Кроме того, проверьте оригинальную бумагу kademlia.