[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r28286 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r28286 - gnunet-java |
Date: |
Wed, 24 Jul 2013 00:06:51 +0200 |
Author: dold
Date: 2013-07-24 00:06:51 +0200 (Wed, 24 Jul 2013)
New Revision: 28286
Modified:
gnunet-java/ISSUES
Log:
issues
Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES 2013-07-23 21:45:32 UTC (rev 28285)
+++ gnunet-java/ISSUES 2013-07-23 22:06:51 UTC (rev 28286)
@@ -1,31 +1,50 @@
-* multihashmap_remove: value should be const, right?
+* i hit the problem of cyclic IBFs again ...
+ * identical subsequent keys => stop
+ * more than ibf->size elements decoded => stop
+ * similar rules apply to strata estimators
-* test_mesh_single
- * for communication over a single tunnel, mesh
- delivered only the first message
- * currently seems broken again
+* running test_set_api is *the* way to trigger all kinds of mesh assertions!
-* set running and tested, gnunet-set-profiler works
- * stuff like cancel, ref-counting for set-ops implemented ;)
- * what should happen if the set's client disconnects? there is currently no
error handler ...
- * yet missing: control flow; how to implement that nicely?
- * after quite some valgrinding and gdb, no memory leaks, no uninitialized
memory (some were in mesh!)
- * discovered the neat --db-attach
- * still random hangups due to mesh
- * I think it's safe to implement dv now
+* worst bug i've had in a long time:
+ https://gnunet.org/bugs/view.php?id=2967
+ * see 1st comment: I can't find any other reason than mesh!
-* as of this morning, mesh has problems again
+* discuss mesh tunnel auto reconnect
+ * bad for state-ful protocols
+ * shouldn't be transparent to the user
+ * there's almost no way for the connection to the service to be lost without
+ the mesh service crashing
-* consensus:
- * mesh currently makes testing impossible
- * semi-honest consensus should work, modulo some bugs ;)
+* discuss set api issues from the bug tracker
+ * when is op cancel necessary?
+ * listener auto reconnect?
-* different set implementations now have a VTable
- * not sure if the new implementation is better: it's shorter code-wise, but
probably harder to
- understand
+* in consensus, we need to present all elements to the client at the end of
conclude
+ * => set now as GNUNET_SET_iterate
-* what C standard is GNUnet using?
- * C99 features? (struct initializers)
+* sounds easier than it is: iterating over a GNUNET_SET's elements.
+ * handling canceling for iterating over a set?
+ * flow control? memory overhead for queue?
+ * any idea how to implement iteration "better"?
-* TODO: update mesh in java
- * when mesh api is nicer
+* mq vs RequestQueue
+ * totally different approach
+ * queueing messages vs maintaining requests
+ * the latter is too complicated/contrived, let's go for mq!
+
+* context: how to do it in java?
+ * plain Object vs Tunnel<T>
+ * latter is nicer, currently implemented
+
+mq for *implementing* the mesh api:
+* observations about sending messages:
+ * messages are virtually never constructed in the ntr callback
+ * message construction is never costly
+ * the only reason I see for using ntr is that you can directly write
+ to a buffer. This argument does not apply to gnunet-java
(org.gnunet.construct)
+ * does not apply to mesh; mesh does not even use the message size
+ * in java: notify transmit really clunky, why use it?
+
+* currently, in gnunet-java a mesh tunnel *is* a message queue with an
additional notifySendReady
+* optional to use, otherwise queued messages are sent when mesh allows it
+
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r28286 - gnunet-java,
gnunet <=