[GNUnet-SVN] r27486 - gnunet-java

[gnunet]

Author: dold
Date: 2013-06-19 12:50:09 +0200 (Wed, 19 Jun 2013)
New Revision: 27486

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-06-19 10:48:54 UTC (rev 27485)
+++ gnunet-java/ISSUES  2013-06-19 10:50:09 UTC (rev 27486)
@@ -1,64 +1,82 @@
-* 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
+The macro invocation
+  GNUNET_CONTAINER_DLL_remove (head, tail, head);
+does not work. had to learn this the hard way ;)
 
-* review shuffle in gnunet-service-consensus
- * one subround finishes correctly, then shuffle/hkdf has problems
+MQ_Message is now MQ_Envelope
+ * old name was confusing, now somewhat suggestive
 
-==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)
+(other rename: SET_evaluate is now SET_prepare, 
+as SET_connect and SET_evaluate both suggest something happens now,)
 
+added GNUNET_STREAM_mq_create ()
+ * send-only mq, obviously
+ * how to handle corking in the API?
 
-* 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?
+MQ structures are fully opaque
+ * more of the logic moved to mq.c
+ * implementations much shorter
+ * review
 
+changed consensus_api.c to use MQ, much less code now
+ * discovered API problem: when insert fails, insert done callback is
+   called with error indicator
+ * _but_: inserts can be queued, and don't have to have an IDC
+ * consensus should indicate failure in another way
+  * e.g. error handler in the constructor
 
-* stream shutdown:
- * still have to call STREAM_close?
- * segfaults for me / calls mesh function with NULL after some time => assert 
fails
+where are mesh ports defined? gnunet_applications.h?
 
-* external protocol violations etc. from stream
- * when is mesh2 ready?
+* how _exactly_ does corking work in mesh?
+ * basic idea: merge multiple write calls to one message
+ * what about flushing? timeouts? etc.
 
-* 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
+* would anyone be offended if I add the doxygen strings to e.g. mesh_api.c?
+ * vim jumps to the definition ;)
 
-* test_set_api still does not work non-deterministically (stops at p2p 
connection)
-* gnunet-set does the same thing, but always works
+* when is the initiator of a tunnel different from the message sender in mesh2?
 
+* return value of mesh2 message handler has unexpected semantics
 
-* set currently uses GNUNET_MQ_msg_nested_mh and GNUNET_MQ_extract_mh as 
replacement for
-  the old nest stuff
+* what happens if the port we request in mesh is used?
+ * lockmanager waits?
+  * what happens in only some ports are free?
 
+* mesh: shutdown not yet documented/implemented
 
-* should have a perf_set_union.c
- * can/should have perf tests command line arguments?
+* simplest way to get random GNUNET_HashCodes with _fixed_ seed
+ * I need this in set profiler to test if salting is correctly implemented
+ * => find seed and salt that collides, and check if other salts don't collide
 
-* 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?
+* not being able to change mesh handlers per tunnel leads to somewhat ugly code
+ * indirection due to the possible states of a tunnel
+  * connected incoming
+  * got peer's request
+  * client accepted request, client started request
 
+* issues with with tunnel context and tunnel_destroy: no way to get at the 
tunnel context
+ * tunnel contexts have to be kept in a linked list as well
+   => more code, more bugs
+* if tunnel_destroy would call the tunnel end handler, there would
+  be no need to have/iterate through a linked list of contexts
 
-* very nice-to-find bug in set: some collisions created a cyclic linked list
 
+some gripes for gnunet-java and mesh:
+ * ipc protocol is still very non-nice to use
 
-todo:
-make MQ_MessageQueue struct opaque
+stuff about mesh2:
+* handlers have to be specified per connection to mesh
+ * there's no reason to do this, except to safe sizeof(pointer) bytes per 
tunnel! 
+ * makes SET very ugly (two "submodules" with different message types)
+ * also would not work with plugins
+ * my suggestion: drop the handlers array, use a single message handler instead
+ * otherwise: how would you implement set intersection/union without code 
duplication?
 
+* handling of tunnel/connection death is not handled consistently across gnunet
+ * why aren't mesh tunnels handled like SERVICE Clients?
+ * need to keep state around for tunnels without
 
+* it's nowhere specified what tunnel buffering is
+* there's a comment in the source, but when will mesh have flow control?
+
+debugging: what is more recent, ./.libs/lt-foo or ./.libs/foo?
+ * lt-foo seems to be created when foo is first executed?