aleks-f / kademlia Goto Github PK

Windows:
I can connect many peers to the bootstrap, no problem (tried 10 all worked). However, if I connect and disconnect the same peer I can only do it twice.( so the same ports..). The 3 rd time it does not properly connect it gets somehow locked when kademlia thread is started. After “killing” the peer (which hangs), no other connection is possible there is an exception thrown if you try to connect ANY peer on any ports. Restarting the bootstrap fixes the problem, and it is consistent (enough to use only one peer, connect to bootstrap, close it, start again, works second time, hangs the third time.

With Poco Kademlia, it happens always, you can connect and disconnect “same peer” (same ports) to bootstrap twice, the third time it fails (the peer practically hangs when it tries to open the session). Restarting the bootstrap will reset the counter but again you can do it twice .However, there is no problem connecting different peers (different ports) one after another, it’s the disconnect/reconnect on the same ports which creates the problem.

Linux:
Bootstrap connections don't seem to work at all on Ubuntu for one peer on a local network and work up to a few times on Windows (2 times before failing after, as Adrian mentioned). We can see that packets are being exchanged but they are not received appropriately by the peer. This has to do with the peer discovery process after initial connection with the bootstrap. We can work on getting these messages passed more efficiently (reducing the total number of packets sent for discovery/bootstrapping), but I wonder if this is an issue with the Proactor's polling mechanism.

For the hanging bug, just to recap, it happens using the “example” programs also, so nothing to do with our own software. Depending on what system you run you may be able to connect 2-3 times but also you may even fail the first time. I suppose if you run in a VM your chance to fail even the first time increases, may have to do with the system running slower, not the OS itself. I see in tests ( enabling logging for Engine and Session) that the initialization messages (hundreds) almost double after each disconnect/reconnect which may explain why even on “fast” systems (Windows runs on bare metal, not VM like we usually run Linux) it will happen after a few connections. In Linux (including WSL) fails the first time. Probably some time hazard when sending/receiving the initialization messages.

I/O reported to be much slower than original kademlia; probably because of the I/O data buffer being dynamically allocated

It is not currently possible to delete an entry from the DB.

see pocoproject/poco#3380

Routing table storage is implemented as a vector<list<pair<id, endpoint>>>. According to specification, the routing table should be a binary tree. Asked about the rationale in DavidKeller/kademlia#10.

Allow settings to be provided dynamically at runtime

Add move semantics to Poco::Net, see pocoproject/poco#3296

See pocoproject/poco#3357

Currently, the I/O has to be "serialized" from outside, which defeats the async nature of the I/O to a significant extent; while internally the I/O requests will be going on between multiple peers for every request, the request round-trip must be "outside shielded" (serialized) to prevent concurrent I/O requests.

There are two main reasons for this limitation:

1. On startup, I/O may begin before Session was completely initialized; this has to do with SocketProactor::IOCompletion running in its own thread. Session constructor should wait for the initial discovery I/O to complete before proceeding and allowing kademlia library I/O operations to be issued.

2. When I/O is running concurrently, loading values sometimes fails with "value not found" error; this manifest itself as a timeout, but increasing the timeout value does not help it - for some reason, some peers fail to respond with the sought for value; a "stopgap" that fixes this problem is to treat the timed out peers as new ("uncontacted") on such occurrence, but the true underlying reason for it should be further investigated (this problem does not happen when the loading operations are serialized)

not needed, and only creates problems

see DatagramSocket does not allow IPV6_V6ONLY

as stated

Look into using some form of UUID instead of random engine generator.

Bug from the original library.

POCO 1.12.0

see POCO issue

pocoproject/poco#3290

UpdatedPocomods.zip