DHT. How to implement trackerless file sharing?

Question

DHT

Hello.
I read the manual on the DHT protocol.
I'm interested in the implementation of trackerless file sharing. Am I understanding the BEP-5
Algorithm correctly ? 1. Make a request to router.utorrent.com: 6881 - get the starting list of nodes. As far as I understand, we do not request info hashes, because in this case, there is no single tracker.

import bencode
import random
import socket


my_id = ''.join([chr(random.randint(0, 255)) for _ in range(20)])
ping_query = {'y': 'q',
          't': '0f',
          'q': 'find_node',
          'a': {'id': my_id}}
ping_query_bencoded = bencode.bencode(ping_query)

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(ping_query_bencoded,
     (socket.gethostbyname('router.bittorrent.com'), 6881))
r = s.recvfrom(1024)
ping_response = bencode.bdecode(r[0])
print(ping_response)

2. Write the nodes in the routing table.

nodes = [
              ["<host>", <port>], 
              ["<host>", <port>]
              ]

3. Using the routing table, we call the nodes to search for the infohash of the file (get_peers) or announce our own infohash (announce_peer)
In which table do we store infohashes from our own and received files?
Do we make a 'ping' request only to router.utorrent.com: 6881 or to all nodes from the routing table?
In this case, we make a 'ping' request once every n seconds - do we show that our node is alive?
Thanks in advance for your replies.

Answer 1

The ID for the node is no longer chosen randomly https://www.bittorrent.org/beps/bep_0042.html
But if it is not supposed to announce and receive requests, then any ID can be chosen. Not all customers have implemented this BEP.
1. router.utorrent.com: 6881 - used only for initial getting of the list of nodes by the find_node command. It doesn't require an info_hash, just the node id and target which can be the same since we're looking for our position on the network.
From now on, router.utorrent.com: 6881 should not be used anymore.
2. The routing table must contain values ​​for each host: id, ip(v4 or v6), port, last response time.
It periodically needs to be saved to disk and at the next start try to boot from it.
3. From the table, the nodes nearest by id to the target or info_hash are selected. And find_node or get_peers are sent to them respectively.
announce_peer is possible only after get_peers because you need an announcement token which is in response to get_peers.
find_node is used to find the nodes closest to its id. You can also periodically look for random id to replenish the routing table.
Accordingly, a separate table is needed in which the list of peers will be stored according to info_hash.
In no case. Work with him is completed at the first stage.
Ping should be sent only to nodes from the routing table with which there has been no connection for a long time. Until the nodes respond to ping, they cannot be given to other nodes for their requests. Accordingly, the nodes received from another node cannot be given further until their status is checked.
Other nodes will also check this by pinging or polling it.