-tiny fix, comments
authorMartin Schanzenbach <mschanzenbach@posteo.de>
Tue, 21 Feb 2012 17:57:52 +0000 (17:57 +0000)
committerMartin Schanzenbach <mschanzenbach@posteo.de>
Tue, 21 Feb 2012 17:57:52 +0000 (17:57 +0000)
src/gns/gnunet-service-gns.c

index 3358be077fc32be3a1a5986b9c7f71d05926d8e7..8222151840225a32e42c5769226f78e6d021607d 100644 (file)
 */
 
 /**
+ *
+ * TODO:
+ *    - Finish dht lookup
+ *    - Think about mixed dns queries (.gnunet and .org)
+ *    - The smaller FIXME issues all around
+ *
  * @file gns/gnunet-service-gns.c
  * @brief GNUnet GNS service
  * @author Martin Schanzenbach
@@ -33,8 +39,7 @@
 #include "gnunet_gns_service.h"
 #include "gns.h"
 
-
-/* TODO into gnunet_protocols */
+/* Ignore for now not used anyway and probably never will */
 #define GNUNET_MESSAGE_TYPE_GNS_CLIENT_LOOKUP 23
 #define GNUNET_MESSAGE_TYPE_GNS_CLIENT_RESULT 24
 
@@ -134,6 +139,20 @@ shutdown_task (void *cls, const struct GNUNET_SCHEDULER_TaskContext *tc)
   GNUNET_DHT_disconnect(dht_handle);
 }
 
+/**
+ * FIXME
+ * This is where it gets tricky
+ * First we store (cache) all replies. Simple.
+ * If we see an authority "closer" to the name
+ * we have to start a new query. Unless we get
+ * a resolution.
+ * It is important that the authority is closer
+ * because else we might end up in an endless loop
+ * (maybe keep track of queried keys?)
+ * Of course we could just limit the resolution
+ * with a timeout (makes sense for clients) but we need
+ * to know when to stop querying.
+ */
 void
 handle_dht_reply(void* cls,
                  struct GNUNET_TIME_Absolute exp,
@@ -190,6 +209,7 @@ process_auth_query(void* cls, const GNUNET_HashCode *zone,
   /**
    * We found a PKEY that may be able to help us
    */
+  query->authority_found = 1;
   GNUNET_HashCode *key = (GNUNET_HashCode*) data;
   
   //FIXME magic number