[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r27486 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r27486 - gnunet-java |
Date: |
Wed, 19 Jun 2013 12:50:09 +0200 |
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?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r27486 - gnunet-java,
gnunet <=