Permalink
Browse files

Import dht-0.15 as a submodule

  • Loading branch information...
1 parent 3d6a816 commit d4cd73559a8bb42448c023c6b0a936fd62980660 @kerneis committed Aug 9, 2011
Showing with 4 additions and 3,744 deletions.
  1. +3 −0 .gitmodules
  2. +1 −0 dht
  3. +0 −96 dht/CHANGES
  4. +0 −19 dht/LICENCE
  5. +0 −9 dht/Makefile
  6. +0 −195 dht/README
  7. +0 −450 dht/dht-example.c
  8. +0 −2,919 dht/dht.c
  9. +0 −56 dht/dht.h
View
@@ -0,0 +1,3 @@
+[submodule "dht"]
+ path = dht
+ url = git://github.com/jech/dht.git
1 dht
Submodule dht added at 66df4e
View
@@ -1,96 +0,0 @@
-1 July 2010: dht-0.15
-
- * Port to Windows, for the needs of Transmission.
-
-25 March 2010: dht-0.14
-
- * Fixed ordering of entries in parameter dictionaries.
-
-15 December 2009: dht-0.13
-
- * Implemented protection against incorrect addresses in the DHT.
- * Tweaked neighborhood maintenance to wake up less often.
-
-11 December 2009: dht-0.12
- * Fixed slightly incorrect formatting of DHT messages.
- * Fixed incorrect debugging message.
-
-22 November 2009: dht-0.11
-
- * Implemented IPv6 support (BEP-32).
- * Fixed a bug which could cause us to never mark a search as finished.
- * Fixed a bug that could cause us to send incomplete lists in response to
- find_nodes.
- * Limit the number of hashes that we're willing to track.
- * Made bucket maintenance slightly more aggressive.
- * Produce on-the-wire error messages to give a hint to the other side.
- * Added a bunch of options to dht-example to make it useful as
- a bootstrap node.
- * Send version "JC\0\0" when using dht-example.
-
-18 October 2009: dht-0.10
-
- * Send nodes even when sending values. This is a violation of the
- protocol, but I have been assured that it doesn't break any deployed
- implementation. This is also what both libtorrent and uTorrent do.
- * Give up immediately on a search peer when no token was provided. This
- is a very reasonable extension to the protocol, and certainly doesn't
- break anything.
- * Parse heterogeneous values lists correctly. This is mandated by BEP 32.
-
-20 September 2009: dht-0.9
-
- * Fixed incorrect computation of number of nodes.
- * Made the initial bucket split eagerly (speeds up bootstrapping).
- * Fixed initial filling of search buckets (speeds up searches).
-
-28 July 2009: dht-0.8
-
- * Fixed a crash when expiring the first search on the list.
- * Fixed freeing of the search list when uniniting with dofree = 1.
-
-24 June 2009: dht-0.7
-
- * Removed the fixed limit on the number of concurrent searches, we now
- use a linked list.
- * Fixed build on FreeBSD (thanks to Humihara and Charles Kerr).
-
-22 May 2009: dht-0.6
-
- * Fixed a buffer overflow (when reading) in parse_message.
- * Fixed slightly inacurrate metric computation when searching.
- * Removed a slightly inaccurate shortcut when responding to find_nodes.
- * Relaxed the rate-limiting parameters to 4 requests per second.
-
-19 May 2009: dht-0.5
-
- * Made reading of /dev/urandom a function provided by the user.
- * Implemented the ``v'' extension that identifies node implementations.
-
-18 May 2009: dht-0.4
-
- * Fixed the handling of tokens in announce_peer messages.
- * Implemented backtracking during search when nodes turn out to be dead.
-
-17 May 2009: dht-0.3
-
- * Fixed a number of incorrectly formatted messages.
- * Changed reply to find_peers to spread the load more uniformly.
- * Fixed a bug that could cause premature splitting.
- * Implemented rate limiting.
- * Changed some time constants to be less chatty.
- * When determining if a bucket is fresh enough, we now only take replies
- into account.
- * dht_get_nodes now returns nodes starting with our own bucket.
- * Tweaked the memory allocation strategy for stored peers.
-
-17 May 2009: dht-0.2
-
- * Fixed a crash in dht_uninit.
- * Added support for saving the list of known-good nodes.
- * Changed the interface of dht_nodes to provide the number of nodes that
- recently sent incoming requests.
-
-13 May 2009: dht-0.1
-
- * Initial public release.
View
@@ -1,19 +0,0 @@
-Copyright (c) 2009 by Juliusz Chroboczek
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.
View
@@ -1,9 +0,0 @@
-CFLAGS = -g -Wall
-LDLIBS = -lcrypt
-
-dht-example: dht-example.o dht.o
-
-all: dht-example
-
-clean:
- -rm -f dht-example dht-example.o dht-example.id dht.o *~ core
View
@@ -1,195 +0,0 @@
-The files dht.c and dht.h implement the variant of the Kademlia Distributed
-Hash Table (DHT) used in the Bittorrent network (``mainline'' variant).
-
-The file dht-example.c is a stand-alone program that participates in the
-DHT. Another example is a patch against Transmission, which you might or
-might not be able to find somewhere.
-
-The code is designed to work well in both event-driven and threaded code.
-The caller, which is either an event-loop or a dedicated thread, must
-periodically call the function dht_periodic. In addition, it must call
-dht_periodic whenever any data has arrived from the network.
-
-All functions return -1 in case of failure, in which case errno is set, or
-a positive value in case of success.
-
-Initialisation
-**************
-
-* dht_init
-
-This must be called before using the library. You pass it a bound IPv4
-datagram socket, a bound IPv6 datagram socket, and your node id, a 20-octet
-array that should be globally unique.
-
-If you're on a multi-homed host, you should bind the sockets to one of your
-addresses.
-
-Node ids must be well distributed, so you cannot just use your Bittorrent
-id; you should either generate a truly random value (using plenty of
-entropy), or at least take the SHA-1 of something. However, it is a good
-idea to keep the id stable, so you may want to store it in stable storage
-at client shutdown.
-
-
-* dht_uninit
-
-This may be called at the end of the session. If dofree is true, it frees
-all the memory allocated for the DHT. If dofree is false, this function
-currently does nothing.
-
-Bootstrapping
-*************
-
-The DHT needs to be taught a small number of contacts to begin functioning.
-You can hard-wire a small number of stable nodes in your application, but
-this obviously fails to scale. You may save the list of known good nodes
-at shutdown, and restore it at restart. You may also grab nodes from
-torrent files (the nodes field), and you may exchange contacts with other
-Bittorrent peers using the PORT extension.
-
-* dht_ping
-
-This is the main bootstrapping primitive. You pass it an address at which
-you believe that a DHT node may be living, and a query will be sent. If
-a node replies, and if there is space in the routing table, it will be
-inserted.
-
-* dht_insert_node
-
-This is a softer bootstrapping method, which doesn't actually send
-a query -- it only stores the node in the routing table for later use. It
-is a good idea to use that when e.g. restoring your routing table from
-disk.
-
-Note that dht_insert_node requires that you supply a node id. If the id
-turns out to be wrong, the DHT will eventually recover; still, inserting
-massive amounts of incorrect information into your routing table is
-certainly not a good idea.
-
-An additionaly difficulty with dht_insert_node is that, for various
-reasons, a Kademlia routing table cannot absorb nodes faster than a certain
-rate. Dumping a large number of nodes into a table using dht_insert_node
-will probably cause most of these nodes to be discarded straight away.
-(The tolerable rate is difficult to estimate; it is probably on the order
-of one node every few seconds per node already in the table divided by 8,
-for some suitable value of 8.)
-
-Doing some work
-***************
-
-* dht_periodic
-
-This function should be called by your main loop periodically, and also
-whenever data is available on the socket. The time after which
-dht_periodic should be called if no data is available is returned in the
-parameter tosleep. (You do not need to be particularly accurate; actually,
-it is a good idea to be late by a random value.)
-
-The parameter available indicates whether any data is available on the
-socket. If it is 0, dht_periodic will not try to read data; if it is 1, it
-will.
-
-Dht_periodic also takes a callback, which will be called whenever something
-interesting happens (see below).
-
-* dht_search
-
-This schedules a search for information about the info-hash specified in
-id. If port is not 0, it specifies the TCP port on which the current peer
-is listening; in that case, when the search is complete it will be announced
-to the network. The port is in host order, beware if you got it from
-a struct sockaddr_in.
-
-In either case, data is passed to the callback function as soon as it is
-available, possibly in multiple pieces. The callback function will
-additionally be called when the search is complete.
-
-Up to DHT_MAX_SEARCHES (1024) searches can be in progress at a given time;
-any more, and dht_search will return -1. If you specify a new search for
-the same info hash as a search still in progress, the previous search is
-combined with the new one -- you will only receive a completion indication
-once.
-
-Information queries
-*******************
-
-* dht_nodes
-
-This returns the number of known good, dubious and cached nodes in our
-routing table. This can be used to decide whether it's reasonable to start
-a search; a search is likely to be successful as long as we have a few good
-nodes; however, in order to avoid overloading your bootstrap nodes, you may
-want to wait until good is at least 4 and good + doubtful is at least 30 or
-so.
-
-It also includes the number of nodes that recently send us an unsolicited
-request; this can be used to determine if the UDP port used for the DHT is
-firewalled.
-
-If you want to display a single figure to the user, you should display
-good + doubtful, which is the total number of nodes in your routing table.
-Some clients try to estimate the total number of nodes, but this doesn't
-make much sense -- since the result is exponential in the number of nodes
-in the routing table, small variations in the latter cause huge jumps in
-the former.
-
-* dht_get_nodes
-
-This retrieves the list of known good nodes, starting with the nodes in our
-own bucket. It is a good idea to save the list of known good nodes at
-shutdown, and ping them at startup.
-
-* dht_dump_tables
-* dht_debug
-
-These are debugging aids.
-
-Functions provided by you
-*************************
-
-* The callback function
-
-The callback function is called with 5 arguments. Closure is simply the
-value that you passed to dht_periodic. Event is one of DHT_EVENT_VALUES or
-DHT_EVENT_VALUES6, which indicates that we have new values, or
-DHT_EVENT_SEARCH_DONE or DHT_EVENT_SEARCH_DONE6, which indicates that
-a search has completed. In either case, info_hash is set to the info-hash
-of the search.
-
-In the case of DHT_EVENT_VALUES, data is a list of nodes in ``compact''
-format -- 6 or 18 bytes per node. Its length in bytes is in data_len.
-
-* dht_hash
-
-This should compute a reasonably strong cryptographic hash of the passed
-values. It should map cleanly to your favourite crypto toolkit's MD5 or
-SHA-1 function.
-
-* dht_random_bytes
-
-This should fill the supplied buffer with true random bytes.
-
-Final notes
-***********
-
-* NAT
-
-Nothing works well across NATs, but Kademlia is somewhat less impacted than
-many other protocols. The implementation takes care to distinguish between
-unidirectional and bidirectional reachability, and NATed nodes will
-eventually fall out from other nodes' routing tables.
-
-While there is no periodic pinging in this implementation, maintaining
-a full routing table requires slightly more than one packet exchange per
-minute, even in a completely idle network; this should be sufficient to
-make most full cone NATs happy.
-
-* Missing functionality
-
-Some of the code has had very little testing. If it breaks, you get to
-keep both pieces.
-
-
- Juliusz Chroboczek
- <jch@pps.jussieu.fr>
Oops, something went wrong.

0 comments on commit d4cd735

Please sign in to comment.