[GNUnet-SVN] r25112 - gnunet-java

[gnunet]

Author: dold
Date: 2012-11-23 10:14:47 +0100 (Fri, 23 Nov 2012)
New Revision: 25112

Modified:
   gnunet-java/ISSUES
Log:
updated issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2012-11-22 19:57:49 UTC (rev 25111)
+++ gnunet-java/ISSUES  2012-11-23 09:14:47 UTC (rev 25112)
@@ -203,13 +203,68 @@
 
 
 
-
-
 * automake stuff:
  * INCLUDES is deprecated:
    http://www.gnu.org/software/automake/manual/automake.html#Program-Variables
    INCLUDES
    This does the same job as AM_CPPFLAGS (or any per-target _CPPFLAGS variable 
if it is used). It is an older name for the same functionality. This variable 
is deprecated; we suggest using AM_CPPFLAGS and per-target _CPPFLAGS instead. 
 
+------------------------------------------
 
+stumbling block: make check uses the service binary in the installed version.
 
+my bug: consensus service does not receive the CLIENT_JOIN message
+due to logging output of util, the client is accepted by the server, the 
client sends the message (notify transmit ready handler is called)
+but the message does not arrive at the service.
+
+why does this not work (in test_consensus_api):
+GNUNET_log_setup ("test_consensus_api", "DEBUG", NULL);
+GNUNET_log (GNUNET_ERROR_TYPE_DEBUG, "hi\n");
+(outputs nothing)
+
+* how do I use gdb with the test wrappers?
+
+* test wrapper: if the test wrapper segfaults, I have to pkill the peer 
manually.
+
+make test_consensus_api does not recreate libgnunetconsensus.la when 
consensus_api.c has changed
+
+warnings after executing tests
+  Nov 21 20:36:07-102628 util-27239 WARNING RSA signature verification failed 
at crypto_rsa.c:1349: Bad signature
+  Nov 21 20:36:07-102676 transport-27239 WARNING External protocol violation 
detected at gnunet-service-transport_validation.c:1152.
+
+* what happens on consensus disconnect? should the api handle this? *can* the 
api even handle this?
+ * lost updates etc., should actually just re-create consensus
+
+* in general, what happens if e.g. during CONSENSUS_insert the connection to 
the consensus service drops?
+ * the api can't really do anything, because the elements are not stored in 
the api, I suggest calling
+   new_element_cb with NULL
+
+
+* make inclusion of the local peer optional? or is this too ugly?
+ * include: starting a session to test consensus locally would require 
knowledge of local PeerIdentity
+ * exclude: starting consensus with a list of peers would require filtering 
the local peer
+ * => compromise, always works
+
+* the initial_elements is a bit non-symmetric
+ * should the api send them in the CLIENT_JOIN message or just do some 
CLIENT_INSERTs?
+ * wouldn't it be nicer to just use inserts and have a CONSENSUS_begin() to 
signal that there is no more available local data
+ * with some methods of storage, initial elements would not be in the required 
format anyway (e.g. DB)
+
+
+* sending elements to the service: should we do something like bart's ack / 
receive windows?
+
+* how do we prevent a "late submission" of a value, which would sabotage 
consensus?
+ * by building a consensus group step by step, and asking all the members of 
the existing
+   consensus group if they also have the update from the peer new to the group
+   => use some commitment protocol (2PC/3PC/etc.)
+ * if members of the old group do not respond timely to the suggestion to the 
new peer, we leave
+   that group, and join a new one with the new peer (and all cooperating peers 
from the old group)
+ * commitment protocols require timeouts. how do we choose/compute/adapt sane 
values for that?
+
+* what would be a canonical example for being in two consensuses?
+ * can this even happen with the above suggestion?
+
+* Fischer, Lynch and Paterson have an important impossibility result for 
consensus.
+ * according to "Stumbling over consensus research: Misunderstandings and 
issues" 
http://research.microsoft.com/en-us/people/aguilera/stumbling-chapter.pdf
+   it is often misunderstood / does not matter that much in practice
+