[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r27253 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r27253 - gnunet-java |
Date: |
Wed, 22 May 2013 12:51:49 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r27253 - gnunet-java,
gnunet <=