[GNUnet-SVN] r27144 - gnunet-java

[gnunet]

Author: dold
Date: 2013-05-15 13:53:00 +0200 (Wed, 15 May 2013)
New Revision: 27144

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-05-15 11:35:47 UTC (rev 27143)
+++ gnunet-java/ISSUES  2013-05-15 11:53:00 UTC (rev 27144)
@@ -1,31 +1,65 @@
-GNUNET_CRYPTO_get_host_identity: is it ok this way?
+CLIENT_receive crashes on
+socket that could not connect before transmitting a message
+(to reproduce: run gnunet-set without a running peer)
 
-problems with stream,  other bug reports
 
-set should be mostly implemented, but will contain many bugs, since it's not 
yet tested
+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== 
 
-every time a set is destroyed, there should be a kind of garbage collection 
based on the generations
-(currently i just set and test for the generations, but never reclaim storage 
for older objects)
 
-different result modes:
- * finishing a set operation in RESULT_FULL entails sending all local elements
-   of the creation generation of the operation, right?
+test_set_api.c has some problems with the host identity
+ * while the same code in gnunet-set.c works
 Yeah.
 
-
-test cases for mq:
- * basic test cases are obvious
- * stream is obvious (but stream has problems atm)
- * how do i test mq for server-client, connection-client?
 => see util/test_server.c
 
+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
 
-GNUNET_CRYPTO_hkdf:
- * not obvious which algorithms to use
 => use crypto_KDF
 
 
+what about code coverage in C?
 
-* elements received by a remote peer are kept seperate from the set's elements
+mq should be in util
+ * used by both consensus and set
+ * some test cases written
+ * but API still somewhat unstable
 
-Sure.
\ No newline at end of file
+
+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
+
+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
+
+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?
+
+
+gnunet-dv should be updated to use gnunet-set
+
+back to consensus ;)
+