[GNUnet-SVN] r27353 - gnunet-java

[gnunet]

Author: dold
Date: 2013-06-03 12:51:03 +0200 (Mon, 03 Jun 2013)
New Revision: 27353

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-06-01 11:49:25 UTC (rev 27352)
+++ gnunet-java/ISSUES  2013-06-03 10:51:03 UTC (rev 27353)
@@ -1,68 +1,64 @@
-test_set_api still does not work because of host identity issues
- * i don't know how to set the servicehome, because it is something like 
/tmp/test_set_api3FjnV5/0 
+* implemented your suggested changes to the set api, still some questions
+ * why would you create an evaluate request when you don't have the set yet?
+   * 'evaluate' is not a very suggestive name here
+ * either the evaluate needs an additional config param,
+   or the op can only sent to the service (and the context msg can only be 
sent) once
+   conclude has been called. currently the behavior is the latter.
+ * can the setop fail before commit has been called?
+  * currently not even possible
+ * your dv code destroys the set before the op continues.
+ * should there be a has_concluded(setop)? otherwise, the client needs to 
store this sometimes
 
-having the non-opaque struct GNUNET_MQ_MessageQueue definition in 
gnunet_mq_lib.h is
-not that nice, but most implementing functions have to access most of the 
data, and the only
-other solution would be to write quite many accessors
+* review shuffle in gnunet-service-consensus
+ * one subround finishes correctly, then shuffle/hkdf has problems
 
-* compiler errors when not including platform.h are not very helpful
+==2050== Conditional jump or move depends on uninitialised value(s)
+==2050==    at 0x4E5E2F8: GNUNET_CRYPTO_hkdf_v (crypto_hkdf.c:170)
+==2050==    by 0x4E5E6FB: GNUNET_CRYPTO_kdf_v (crypto_kdf.c:62)
+==2050==    by 0x4E5E789: GNUNET_CRYPTO_kdf (crypto_kdf.c:85)
+==2050==    by 0x403193: subround_over.part.3 (gnunet-service-consensus.c:376)
 
 
-back to consensus:
+* implementing an evil consensus peer:
+ * #ifdef EVIL ... #endif
+ * TESTBED_test_run and TESTBED_peer_update_configuration don't work together 
nicely
+  * peers in test_master are already started
+  * should I use peer_stop/update/peer_start, or is there a nicer way,
+    without configuring the whole testbed myself?
 
-basic description of rounds and the grade-cast at 
-https://gnunet.org/svn/gnunet-java/doc/consensus.pdf
 
+* stream shutdown:
+ * still have to call STREAM_close?
+ * segfaults for me / calls mesh function with NULL after some time => assert 
fails
 
-two cases of un-availability:
- * the consensus service is not up yet
- * the consensus session has not yet been created
-=> I don't see a reason to handle those cases differently,
-   the other peer will have to retry (there's no "on-hold" list anymore)
-=> we have one set listener per session, with different respective app_id's
+* external protocol violations etc. from stream
+ * when is mesh2 ready?
 
-does it make sense to use GNUNET_SET_Element instead of consensus elements in 
the consensus api?
+* how should GNUNET_MQ handle stuff like stream's shutdown? two possibilities:
+ * "generic" handler for "special conditions" like errors, timeouts, shutdowns
+ * the function that creates the MQ for stream has an additional cb param for 
this
 
-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)
+* test_set_api still does not work non-deterministically (stops at p2p 
connection)
+* gnunet-set does the same thing, but always works
 
-transfering elements:
- * should we add functions to set that can send all elements over a client 
handle, or is this too far-fetched?
- * GNUNET_SET_send_elements (client, msg_type);
 
-there should be an iterate function for SET
- * e.g. to remove all elements from our set that are not in the final inventory
- * GNUNET_SET_iterate_elements
+* set currently uses GNUNET_MQ_msg_nested_mh and GNUNET_MQ_extract_mh as 
replacement for
+  the old nest stuff
 
-I'm currently trying to understand gradecast better.
- * what would happen without Step 3?
-  * only relevant if the re-broadcasting peers are faulty
 
-http://arxiv.org/pdf/1007.1049v3.pdf
-question about the ByzConsensus algorithm: why isn't one gradecast enough?
-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.
+* should have a perf_set_union.c
+ * can/should have perf tests command line arguments?
 
+* having both GNUNET_SET_add_element and GNUNET_CONSENSUS_insert feels a bit 
redundant
+ * but, there are the problems we discussed last meeting for passing arround 
sets between
+   different processes.
+ * any idea how to make things less redundant, or should we kepe the current 
state?
 
-consensus actually needs some more functionality from set for convenience
- * GNUNET_SET_send_elements_to_client
 
+* very nice-to-find bug in set: some collisions created a cyclic linked list
 
-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?
 
+todo:
+make MQ_MessageQueue struct opaque
 
 
-what is the new experimentation daemon?
-
-void
-GNUNET_SCHEDULER_shutdown ()
-shouldn't there be a void? ;)
-