[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r25112 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r25112 - gnunet-java |
Date: |
Fri, 23 Nov 2012 10:14:47 +0100 |
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
+
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r25112 - gnunet-java,
gnunet <=