[GNUnet-SVN] r26351 - gnunet-java

[gnunet]

Author: dold
Date: 2013-03-07 15:19:33 +0100 (Thu, 07 Mar 2013)
New Revision: 26351

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-03-07 14:12:11 UTC (rev 26350)
+++ gnunet-java/ISSUES  2013-03-07 14:19:33 UTC (rev 26351)
@@ -1,72 +1,80 @@
 
-* Writing down the details: How / How formal should I do it?
+* if a peer does something bad, should we give it a chance to re-try, or just 
treat it as failed?
 
-* IBF implemented with 8-bit count, 64-bit key, 32-bit checksum
- * improved decoding algorithm by checking locations generated by hash in 
(supposedly) pure bucket
- * 1mio elements take ~25sec on my machine, scales linearly
-  * performance in the last version was better, because now there's one more 
call to CRYPTO_hash to generate
-    the ~4 32-bit indices from the 64-bit key
+* 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?
 
-(
-* one problems with IBFs that is solvable (solution by original authors in 
another paper):
- * inserting the same element twice poisons the associated buckets
- * .. but that is not really a problem, as we just won't insert an element 
twice
- * problem with hash-collisions though
- * author's solution: don't XOR, add, check for divisibility of id-sum by count
-)
+* 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.
 
-* the order of the IBF should be its salt
 
-* mapping between keys<->hashcodes
- * i don't think there is the need for any *additional* mapping,
-   just map uint64_t to GNUNET_CONSENSUS_Element
- * there's now ibf_key_to_hashcode and ibf_hashcode_to_key
-  * endianess wrt hashcode: how do i get the first 64bit in a 
platform-independent way?
-   * ok, found GNUNET_ntohll
+* 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?
 
-* why doesn't multihashmap_contains return an integer (=how many elements does 
the key have)?
- * would be nice, so I can pre-allocate an array
+* discuss exchange after inventory for ballot stuffing
 
-* assume we multiple CONSENSUS_Elements in one message
- * how do we handle alignment?
+* discuss heuristic to use
+ * set operations neede, use multihashmap?
+  * misses e.g. copy operation
 
-* handling 64-bit collisions
- * just send/request all values associated with the key
+* handling elements that hash into the same IBF_Key
 
-* stream api
- * write is not very useful, as we have to either allocate a buffer or point 
it to an existing one
- * but, in the second case, we can't splice together information from multiple 
places
-   as we have to wait for the continuation.
- * stuff like sending all values for a key in a multihashmap gets messy
+* I'm not sure about client acks
+ * but they're implemented right now
 
-* what are min-wise hashes, and does it make sense to use them for higher 
(=less elements) strata, as in the paper?
- * I know what they are by know
- * i think implementing them is very low priority
+* C: can't assign pass "T**" to fn expecting "const T**"
+ * ok, reason here: http://c-faq.com/ansi/constmismatch.html
 
-* how do I expose the key in the IBF api? currently it's pass-by-value 
uint64_t,
-  which I like, as I don't see a need to hide the type.
+* the implementation is now state-machine-ish with current_round and ibf_state
 
-* how well would a group-selection based on repeatedly adding the peer with
-  the greatest similarity to all others work?
- * => greedy algorithm
- * what are pathological cases where it works badly?
-  * ... and can those be exploited?
- * could it be good enough for most cases?
- * easy to implement, no combinatorial explosion
- * it's easy to compute pairwise similarity with strata estimators of a2a round
+* 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
 
-* do we agree that the client should only get one consensus group on conclude?
+* ibf now has IBF_Key, IBF_KeyHash, more consistent naming (key vs id)
 
-conclude process:
- * (implement later) exponential exchange
- * a2a exchange
- * a2a inventory
- * (implement later) inventory agreement / fraud detection
- * group finding
+* ibf_write / ibf_read in a loop and alignment
+ * should i just align with "buf = (buf + 63) & ~63"?
 
-anything to add?
+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
 
 
+#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
 
+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==