[GNUnet-SVN] r27252 - gnunet-java

[gnunet]

Author: dold
Date: 2013-05-22 12:36:20 +0200 (Wed, 22 May 2013)
New Revision: 27252

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-05-22 10:29:15 UTC (rev 27251)
+++ gnunet-java/ISSUES  2013-05-22 10:36:20 UTC (rev 27252)
@@ -1,70 +1,67 @@
-CLIENT_receive crashes on
-socket that could not connect before transmitting a message
-(to reproduce: run gnunet-set without a running peer)
---- MQ bug, never receive before sending at least one MSG.
+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 
 
+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
 
-// FIXME: zero 'reserved' field.
-I can't track down the uninitialized bytes error in gnunet-set
-(only happens once)
-==4516== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
-==4516==    at 0x539BEBD: send (send.c:27)
-==4516==    by 0x4E6BCFF: GNUNET_NETWORK_socket_send (network.c:688)
-==4516==    by 0x4E4EEF3: transmit_ready (connection.c:1325)
-==4516==    by 0x4E76CB8: GNUNET_SCHEDULER_run (scheduler.c:597)
-==4516==    by 0x4E71E8A: GNUNET_PROGRAM_run2 (program.c:273)
-==4516==    by 0x400BBE: main (gnunet-set.c:194)
-==4516==  Address 0x71678d4 is 4 bytes inside a block of size 13 alloc'd
-==4516==    at 0x4C2CF8E: realloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
-==4516==    by 0x4E48D6C: GNUNET_xrealloc_ (common_allocation.c:177)
-==4516==    by 0x4E4F064: transmit_ready (connection.c:1311)
-==4516==    by 0x4E76CB8: GNUNET_SCHEDULER_run (scheduler.c:597)
-==4516==    by 0x4E71E8A: GNUNET_PROGRAM_run2 (program.c:273)
-==4516==    by 0x400BBE: main (gnunet-set.c:194)
-==4516== 
+* compiler errors when not including platform.h are not very helpful
 
 
-test_set_api.c has some problems with the host identity
- * while the same code in gnunet-set.c works
-Yeah.
-=> check config used
+back to consensus:
 
-=> see util/test_server.c
+basic description of rounds and the grade-cast at 
+https://gnunet.org/svn/gnunet-java/doc/consensus.pdf
 
-gnunet-set (currently just a simple test, should actually insert variable 
number of elements)
- * why is there a collision on those elements?
- * larger IBF has to be used
 
-=> use crypto_KDF
+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
 
+does it make sense to use GNUNET_SET_Element instead of consensus elements in 
the consensus api?
 
-what about code coverage in C? cat svn/gnunet/contrib/coverage.sh 
+is there any communication step where we *can't* solely rely on the SET 
context message?
 
+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);
 
-mq should be in util
- * used by both consensus and set
- * some test cases written
- * but API still somewhat unstable
+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
 
+I'm currently trying to understand gradecast better.
+ * what would happen without Step 3?
+  * only relevant if the re-broadcasting peers are faulty
 
-silly-ish question: how do I print a uint32_t?
-PRIu32 from inttypes.h (C99) would be the "most correct" way, but nobody uses 
it
- fprintf (stderr, "%u", (unsigned int) i);
+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.
 
-what should happen if we can not send our responses (stream failure), but we 
already got a done?
- * either ignore it
- * or always wait until our send queue is emptied and then notify the client 
of success or failure
-  * currently implemented
+* how do I implement grade-cast in consensus, api-wise?
 
-debugging: is there any good way to get the scheduled tasks
-in readable form (function pointers resolved to symbols) in e.g. GDB
- * when a gnunet program does not terminate
 
-currently timeouts are only implemented in the client
- * it should be like this, right?
+final protocol:
+ * do exp scheme
+  * this uses one GNUNET_SET per session
+ * all-to-all gradecast each peer's inventory
+  * 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?
 
 
-gnunet-dv should be updated to use gnunet-set
+consensus actually needs some more functionality from set for convenience
+ * GNUNET_SET_send_elements_to_client
 
-back to consensus ;)
 
+
+what is the new experimentation daemon?
+
+void
+GNUNET_SCHEDULER_shutdown ()
+shouldn't there be a void? ;)
+