From 928a2934ab9cfc7386269b756e1ce815059be3a9 Mon Sep 17 00:00:00 2001 From: Cameron Dale Date: Tue, 4 Mar 2008 16:04:40 -0800 Subject: [PATCH] More todo items. --- TODO | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/TODO b/TODO index b495193..192670b 100644 --- a/TODO +++ b/TODO @@ -1,3 +1,15 @@ +Evaluate and fix some errors in the ktable khashmir module. + +The KTable implementation has some possible errors in it. insertNode +does not remove the original and use the new node when updating a node +already in the table, as claimed by the comments. justSeenNode doesn't +verify that the found node is the node that was being looked for, nor +does it move the node to the end of the list of nodes (since they are +supposed to be sorted by their lastSeen time) or update the bucket's +last touched time.nodeFailed also doesn't verify the found node is the +right node. + + Consider what happens when we are the closest node. In some of the actions it is unclear what happens when we are one of the @@ -47,3 +59,20 @@ originally provided the piece is probably at fault, since he is now providing a later piece. This doesn't work if the differing piece is the first piece, in which case it is downloaded from a 3rd peer, with consensus revealing the misbehaving peer. + + +Consider adding peer characteristics to the DHT. + +Bad peers could be indicated in the DHT by adding a new value that is +the NOT of their ID (so they are guaranteed not to store it) indicating +information about the peer. This could be bad votes on the peer, as +otherwise a peer could add good info about itself. + + +Consider adding pieces to the DHT instead of files. + +Instead of adding file hashes to the DHT, only piece hashes could be +added. This would allow a peer to upload to other peers while it is +still downloading the rest of the file. It is not clear that this is +needed, since peer's will not be uploading and downloading ery much of +the time. -- 2.30.2