[GNUnet-SVN] r26530 - gnunet-java

[gnunet]

Author: dold
Date: 2013-03-21 02:54:48 +0100 (Thu, 21 Mar 2013)
New Revision: 26530

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-03-21 01:53:58 UTC (rev 26529)
+++ gnunet-java/ISSUES  2013-03-21 01:54:48 UTC (rev 26530)
@@ -1,122 +1,70 @@
+* discuss topology in exp round
+ * analytical solution?
+ * degenerate cases (e.h. n=3)
 
-* if a peer does something bad, should we give it a chance to re-try, or just 
treat it as failed?
+* related to your bug-report:
+==7580== Invalid read of size 4
+==7580==    at 0x65221E0: send_connect (mesh_api.c:803)
+==7580==    by 0x6527409: reconnect_cbk (mesh_api.c:876)
+==7580==    by 0x4E76FB8: GNUNET_SCHEDULER_run (scheduler.c:597)
+==7580==    by 0x4E81BB5: GNUNET_SERVICE_run (service.c:1816)
+==7580==    by 0x4017A5: main (gnunet-service-consensus.c:2769)
+==7580==  Address 0x7fefff830 is just below the stack ptr.  To suppress, use: 
--workaround-gcc296-bugs=yes
+==7580== 
 
-* discuss how to build tests for consensus
- * currently gnunet-consensus only allows to specify how many peers get each
- * probably should be able to specify (normal) distribution of differences
- * any other parameters?
- * this is only for measuring performance in the case where everything works,
-   we discusses how we might test other cases (config or special api calls),
-   but *what* do we want to test?
+ * occurs sometimes, don't know if my fault or stream/mesh
 
-* In general, does it make sense to wait for k-1 successful interactions in 
the round?
-  we should ignore timeouts, until we have synced with k peers.
+ * problem with gnunet-consensus and testbed on shutdown, what am I doing 
wrong?
+  * doing operation_done on the handles returned by service_connected fixed 
some of the assertion errors
 
+ * there are two stages of done: *we* have all elements, vs. enough other 
peers have all elements
 
-* Adding more than k peer cans only *removes* values, never add any.
-  So why would we not want to stop at k peers for the consensus group?
+ * tbd: testing response to non-decodable IBF
+  * how to test this systematically?
+  * e.g. GNUNET_CONSENSUS_flout_scramble_ibfs (double probability)
+ * tbd: testing if the inventory phase actually works
+  * some elements must be missing for this
+  * use GNUNET_CONSENSUS_flout_drop_elements (double probability)
 
-* discuss exchange after inventory for ballot stuffing
+ * different peers can be in different rounds (one in inventory, other in 
stock)
+  * IBFs, SEs, SYNCs and FINs have to be tagged with their round
 
-* discuss heuristic to use
- * set operations neede, use multihashmap?
-  * misses e.g. copy operation
+ * implementing the stock round, just use exp scheme or more explicit exchange 
(we know which peer wants/has which element)
 
-* handling elements that hash into the same IBF_Key
+ * some delicate bugs, e.g. related to double insertion bucket poisoning
 
-* I'm not sure about client acks
- * but they're implemented right now
+ * gave up on state-machine for sending messages to other peers
+  * there's one queue per peer now
 
-* C: can't assign pass "T**" to fn expecting "const T**"
- * ok, reason here: http://c-faq.com/ansi/constmismatch.html
+ * replay of premature SE's
+  * if we don't expect a strata message, store it, and check
+    on start of next round if we could use it right now
 
-* the implementation is now state-machine-ish with current_round and ibf_state
+ * in what way is it expensive to keep a tunnel/stream connection open?
+ * related question: when should we start connecting to other peers?
+  * currently: after conclude call
 
-* how can you iterate *keys* of a hash table?
- * I need this to populate IBFs, as double inserts poison the IBF
- * GNUNET_CONTAINER_multihashmap_iterate_keys
+ * implementing peer shuffle
+  * currently shuffle is a no-op
+  * should use bits from global session id, right?
 
-* ibf now has IBF_Key, IBF_KeyHash, more consistent naming (key vs id)
+ * I'm using queues for messages quite often, am I doing something wrong?
+  * client messages are queued
+  * messages to other peers are queued
 
-* ibf_write / ibf_read in a loop and alignment
- * should i just align with "buf = (buf + 63) & ~63"?
+ * dealing with hash collisions in the inventory phase
+  * previous phase is fine
 
-found http://www.cse.ust.hk/~liu/guodeke/TKDE2012.pdf
-* looks like a rip-off of the eppstein/goodrich paper?
- * only at first sight, their method is much complicated and worse
-* does not cite them
-* accepted at IEEE Transactions on Knowledge and Data Engineering
+ * doing inventory in nlogn:
+  * can't IBFs be used as commutative cryptographic hash?
+  * messages then would be:
+   * id-list (peer ibf sign plus minus)*
+ * but: when we do direct exchange, we know that the other peer knows that we 
don't have an element, so we don't have to
+   request it explicitly
 
+ * consensus service implementation is one very big file, any idea how to 
structure it nicely?
 
-#define GNUNET_array_append(arr,size,element) do { 
GNUNET_array_grow(arr,size,size+1); arr[size-1] = element; } while(0)
-* not safe to use, as size is evaluated multiple times
-* operator precedence issues (no parens)
-* AFAIK docs don't mention size is changed
+ * problem with the log-scheme
+  * if there's one slow peer, the whole consensus will be slow
+  * any way to mitigate this?
 
-http://www.cs.unc.edu/~reiter/papers/1995/Dagstuhl.pdf
- * this is what the authors of the voting protocol suggest
- * basically byzantine agreement with state machine replication, ordering of 
requests
- * to cast a vote, a voter has to contact multiple servers, wait until k 
servers process the request,
-   wait for multiple answers
-  * is this some kind of joke? ;)
- * we somehow have to argue that our approach is better
- * their advantage: no vote can get lost
- * their disadvantage: the client has to wait for response from k to n servers,
-   unpredictable latency due to other requests being processed
-
-our only problem compared to their approach: we can't offer any guarantee that 
a vote will count,
-even if we deliver it to k+1 authorities.
-
-
-
-^CMar 07 14:26:52-685537 gnunet-consensus-6685 WARNING Controller crash 
detected. Shutting down.
-==6707== Invalid read of size 4
-==6707==    at 0x65201E0: send_connect (mesh_api.c:803)
-==6707==    by 0x6525409: reconnect_cbk (mesh_api.c:876)
-==6707==    by 0x4E75C58: GNUNET_SCHEDULER_run (scheduler.c:597)
-==6707==    by 0x4E80285: GNUNET_SERVICE_run (service.c:1816)
-==6707==    by 0x4016A5: main (gnunet-service-consensus.c:2372)
-==6707==  Address 0x7fefef860 is not stack'd, malloc'd or (recently) free'd
-==6707== 
-
-Build problems:
-libmicrohttpd: ./configure does not detect missing makeinfo
- * on ubuntu, texinfo package missing, not 100% obvious
-
address@hidden:~/repos/Extractor$ ./bootstrap 
-Can't exec "autopoint": No such file or directory at 
/usr/share/autoconf/Autom4te/FileUtils.pm line 345.
-autoreconf: failed to run autopoint: No such file or directory
-autoreconf: autopoint is needed because this package uses Gettext
-
-
-gnunet-gns-proxy.c:28:23: fatal error: curl/curl.h: No such file or directory
-compilation terminated.
-
-calling contrib/pogen.sh, as a gnunet dev I know this fixes the
-build problem, but not obvious!
-
-
-gnunet has problems with make -j4:
-[...]
-  CC     testbed_api_hosts.lo
-  CC     testbed_api_services.lo
-  CC     testbed_api_operations.lo
-  CC     testbed_api_statistics.lo
-  CC     testbed_api_peers.lo
-  CC     testbed_api_testbed.lo
-  CC     testbed_api_test.lo
-  CC     testbed_api_topology.lo
-  CC     testbed_api_sd.lo
-  CC     gnunet-service-testbed.o
-  CC     gnunet-service-testbed_cache.o
-make[3]: *** No rule to make target `../../src/testbed/libgnunettestbed.la', 
needed by `gnunet-service-testbed'.  Stop.
-make[3]: *** Waiting for unfinished jobs....
-  CC     gnunet-service-testbed_oc.o
-gnunet-service-testbed_cache.c: In function ‘cache_get_handle’:
-gnunet-service-testbed_cache.c:803:40: warning: ‘op’ may be used uninitialized 
in this function [-Wmaybe-uninitialized]
-make[3]: Leaving directory `/home/dold/repos/gnunet/src/testbed'
-make[2]: *** [all-recursive] Error 1
-make[2]: Leaving directory `/home/dold/repos/gnunet/src'
-make[1]: *** [all-recursive] Error 1
-make[1]: Leaving directoy
-