[GNUnet-SVN] r27253 - gnunet-java

[gnunet]

Author: dold
Date: 2013-05-22 12:51:49 +0200 (Wed, 22 May 2013)
New Revision: 27253

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-05-22 10:36:20 UTC (rev 27252)
+++ gnunet-java/ISSUES  2013-05-22 10:51:49 UTC (rev 27253)
@@ -24,6 +24,7 @@
 does it make sense to use GNUNET_SET_Element instead of consensus elements in 
the consensus api?
 
 is there any communication step where we *can't* solely rely on the SET 
context message?
+ * maybe step 3 of the gradecast? (would only require a hash)
 
 transfering elements:
  * should we add functions to set that can send all elements over a client 
handle, or is this too far-fetched?
@@ -42,23 +43,23 @@
 got it: because it's a different starting situation, peers may (validly) have
 different values, and must agree on one value. we don't have this situation.
 
-* how do I implement grade-cast in consensus, api-wise?
 
+consensus actually needs some more functionality from set for convenience
+ * GNUNET_SET_send_elements_to_client
 
+
 final protocol:
  * do exp scheme
   * this uses one GNUNET_SET per session
  * all-to-all gradecast each peer's inventory
+  * that is a lot of hashes to store, how do we handle this 
implementation-wise?
+   * 2*n*n inventory sets
   * instead of sending the message, reconcile the inventory
  * exchange missing elements
   * should this round even exist? can't we exchange elements in the prior 
round instead?
 
 
-consensus actually needs some more functionality from set for convenience
- * GNUNET_SET_send_elements_to_client
 
-
-
 what is the new experimentation daemon?
 
 void