Next: , Up: Using the DHT   [Contents]

4.7.1 Storing data in the DHT

Since the DHT is a dynamic environment (peers join and leave frequently) the data that we put in the DHT does not stay there indefinitely. It is important to “refresh” the data periodically by simply storing it again, in order to make sure other peers can access it.

The put API call offers a callback to signal that the PUT request has been sent. This does not guarantee that the data is accessible to others peers, or even that is has been stored, only that the service has requested to a neighboring peer the retransmission of the PUT request towards its final destination. Currently there is no feedback about whether or not the data has been sucessfully stored or where it has been stored. In order to improve the availablilty of the data and to compensate for possible errors, peers leaving and other unfavorable events, just make several PUT requests!

message_sent_cont (void *cls,
                   const struct GNUNET_SCHEDULER_TaskContext *tc)
  // Request has left local node

struct GNUNET_DHT_PutHandle *
GNUNET_DHT_put (struct GNUNET_DHT_Handle *handle,
                const struct GNUNET_HashCode *key,
                uint32_t desired_replication_level,
                enum GNUNET_DHT_RouteOption options,
                enum GNUNET_BLOCK_Type type,
                size_t size,
                const void *data,
                struct GNUNET_TIME_Absolute exp,
                struct GNUNET_TIME_Relative timeout,
                GNUNET_DHT_PutContinuation cont, void *cont_cls)

Exercise: Store a value in the DHT periodically to make sure it is available over time. You might consider using the function GNUNET\_SCHEDULER\_add\_delayed and call GNUNET\_DHT\_put from inside a helper function.