[GNUnet-SVN] r25867 - gnunet-java

[gnunet]

Author: dold
Date: 2013-01-24 03:57:13 +0100 (Thu, 24 Jan 2013)
New Revision: 25867

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-01-24 02:55:31 UTC (rev 25866)
+++ gnunet-java/ISSUES  2013-01-24 02:57:13 UTC (rev 25867)
@@ -1,134 +1,66 @@
 
-== meeting January 3, 2013 ==
+* what currently (somewhat) works:
+ * connecting with the right topology
+ * exchanging strata, ibfs, values
 
-* https://gnunet.org/bugs/view.php?id=2720
- * had no idea where to look for this
- * non-deterministic
- * "pkill -9 gnunet" gets annoying ;)
+BUT currently sometimes crashes mesh (=>segfault), very hard to reproduce
 
-* rounds:
- 1. every peer broadcasts its set difference estimator
- 2. every peer responds to incoming difference estimators with its ibf of 
appropriate size
-  * but max. one response per round per other peer
-  * should we do this naively, or coalesce them as much as possible?
- 3. every peer responds to the IBF with the actual elements (not hashes) that 
only he has,
-    as well as a list of hashes, where he needs the actual elements.
- 4. every peer receives the actual elements, and element requests, sends 
missing elements of the other peer
- 5. every peer receives the rest of the missing elements
-* => naive implementation doubles the work (as every peer pair sends/receives 
one estimator respectively),
-  any way to make the protocol better w.r.t. this?
-* how do we determine the time for one round?
+* what's next
+ * consensus groups
+ * retries, when IBFs don't decode
+  * do we double the size, or change the salt?
 
-* how reliable of an indicator is an empty strata estimator?
- * bad, when we have large sets, there will always be overflows in the high 
frequency strata
- 
-* benchmarks / measurements of quality for consensus
- * how do we judge the quality of consensus implementation for challenging 
situations?
 
-* GNUNET_MESH_peer_request_connect_add, can it fail, how can it fail, what is 
the timeout (see docs)?
+* memory errors in c are too much fun to debug!
+ * then valgrind saved a lot of time
+  * but the stack traces are strange, how do I disable optimization?
 
-* in mesh, tunnels are two-way. each peer has a broadcast tunnel, and incoming 
tunnels from other peers.
- * now there are two ways to send a message to another peer, which of the 
tunnels is preferable / does is even matter?
-  * i.e., is there a performance difference in to-origin vs. unicast?
+==19221== Conditional jump or move depends on uninitialised value(s)
+==19221==    at 0x5D054E0: inflateReset2 (in 
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
+==19221==    by 0x5D055D8: inflateInit2_ (in 
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
+==19221==    by 0x5D004F5: uncompress (in 
/lib/x86_64-linux-gnu/libz.so.1.2.3.4)
+==19221==    by 0x529F7A3: helper_mst (testbed_api.c:1313)
+==19221==    by 0x4E78C10: GNUNET_SERVER_mst_receive (server_mst.c:265)
+==19221==    by 0x4E66C65: helper_read.part.0 (helper.c:302)
+==19221==    by 0x4E74F80: GNUNET_SCHEDULER_run (scheduler.c:597)
+==19221==    by 0x4E6E87F: GNUNET_PROGRAM_run2 (program.c:273)
+==19221==    by 0x4E6EA69: GNUNET_PROGRAM_run (program.c:308)
+==19221==    by 0x52ADD6A: GNUNET_TESTBED_test_run (testbed_api_test.c:153)
+==19221==    by 0x400E9E: run (gnunet-consensus.c:296)
+==19221==    by 0x4E6E946: GNUNET_PROGRAM_run2 (program.c:278)
 
-* the number of possible groups is very large, shouldn't we restrict their 
number?
- * shouldn't we introduce this as another parameter for conclude?
-* assume every peer in our session is either muted or in agreement, how do we 
proceed with generating the groups?
- * how do we generate/rank the groups?
 
-* interpretation of infinity as timeout for conclude: only stop exchaning once 
we have perfect consensus
+---------------------------------------------------
 
-* what is there to say about broadcast performance in gerneral?
-* bart talked about NSE style broadcast, what is this?
+==20385== Invalid read of size 4
+==20385==    at 0x651E100: send_connect (mesh_api.c:803)
+==20385==    by 0x65232E7: reconnect_cbk (mesh_api.c:876)
+==20385==    by 0x4E74F80: GNUNET_SCHEDULER_run (scheduler.c:597)
+==20385==    by 0x4E7F6C5: GNUNET_SERVICE_run (service.c:1815)
+==20385==    by 0x401475: main (gnunet-service-consensus.c:1827)
+==20385==  Address 0x7fefef830 is not stack'd, malloc'd or (recently) free'd
+==20385== 
 
-* Jan 02 22:03:52-356968 core-api-22511 INFO (Re)connecting to CORE service, 
monitoring messages of type 0
- * how does that make sense?
 
+* something i use printf's stuff, how do i find out what?
+ * looks like output from mesh, seen while running mesh test cases
+ * numbers, like 1228
 
-* IBF hash function: there's no need to have a cryptographic hash, as no 
randomization is possible,
-  and the domain of the hash function actually is really small. To find one 
collision on an IBF with n buckets, on average
-  we only have to try n random values, there's no need to find a SHA-256 
collision
-  fine.
 
-* when the client violates the protocol, what should the service do? Hang up 
(close TCP connection), keep going.
- * most services use GNUNET_break? Yes.
- * which is not very helful, as developers for other bindings (e.g. java ;) 
have to look up the right line in the c code,
-   with no error message; that's what you have the file name and line number 
for!
+* currently, the consensus protocol implementation is a bit chaotic, any ideas 
on what to improve?
+ * except for the usual, comments etc.
 
-* GNUNET_APPLICATION_TYPE_END obvious, but not documented -- eh, it is.
+* are client acks necessary now?
 
 
------------------------------------------------------------------
 
-== Meeting January 10 ==
+Enumerating Groups:
+* would it make sense only to _not include_ a peer into a group if we'd
+  lose >x elements? this makes the search space smaller, but we may lose some 
votes.
 
+For voting:
+* does first generating all groups, and then agreeing on one of them even make 
sense?
+* 
http://csis.bits-pilani.ac.in/faculty/murali/aos-09/papers/Byzantine%20Agreement%20in%20the%20Full-Information%20Model%20in%20O-log-n%20Rounds%20-%20Ben-Or%20Vaikuntanathan%20Pavlov.pdf
+ * describes the graded broadcast with n^2 communication complexity
+ * can we somehow use these ideas?
 
-* suggestion for the stream api:
- * read should take the minimum number of bytes expected
-
-
-* minor flaw in the eppstein/sigcomm paper, when d=0 => d*\alpha = 0 => no 
buckets :(
-* how do we determine the IBF size in this case?
- * constant size 1, is this sufficient?
-
-* how complete is the STREAM implementation?
- * had a quick look at the source, there seem to be some todo's left / some 
rough edges
-
-
-* what should happen if there's two incoming tunnels from one authority, or a 
tunnel gets destroyed?
-* should there be a hello message, to exchange the global consensus id of a 
tunnel, or should this just happen on the first reconciliation message?
-
-* ibf creation is expensive, should we merge responses in the all-to-all case?
-
-in the nlogn round: we should only accept incoming IBFs that are expected, 
right?
-
-* how do we align a 32-bit-array after an 8-bit array?
- * on a multiple of 32?
- * ok, actually obvious: the 32-bit array comes before the 8-bit array
-
-
-* how do we handle lost messages?
- * AFAIK stream does not allow multicast
-
-* how do we patch messages together? is this the right way?
-
-* GNUNET_CRYPTO_hash_cmp can't safely used with qsort
-
-reconciliation rotocol:
-Peer A initiates reconciliation with Peer B
-
-1. Peer A sends SE_A to Peer B, repeatedly with exponential back-off, until it 
A reveices IBF_B from B.
-   From IBF_B, A knows delta.
-2. * Peer A sends IBF_A to B, until all values from B have been received.
-   * Peer A sends values to B, until B has received all values
-
-
----------------------------------------------------
-
-* as interactivity is not possible anymore, gnunet-consensus is now
-  a profiler for consensus, you can spefify timeout, n, k, #elements, etc.
- * how would I simulate "bad" peer and various other conditions?
-
-* do we need to handle reconnecting streams, or do we see this as a peer 
failure?
- * i.e., how robust is a stream connection
-
-* when i want to debug a service, i usually prefix gdbserver,
-  how would this be possible with multiple peers? is there something like 
$SERVICE_PID?
-
-* not sure if i understand purge parameter of mst_receive
- * does it just discard buffer after complete message?
-
-* mst has no way to change callback without discarding buffer.
- * awkward when socket is identified with session
-
-* what is GNUNET_TESTBED_DisconnectAdapter for? Why is the return value of the 
adapters even
-  necessary?
-
-* GNUNET_TESTBED_service_connect: why callback *and* closure for event?
-
-* GNUNET_STREAM_write: "If size is greater than this it is not an API
-  violation, however only the said number of maximum bytes will be written."
-* why is the stream api so different client/mesh/core (i.e. why do i have to 
allocate a buffer, pass it, free it?)
-* what I am supposed to do with the size parameter of the write continuation?
- 
-