[GNUnet-SVN] r25807 - gnunet-java

[gnunet]

Author: dold
Date: 2013-01-17 01:55:58 +0100 (Thu, 17 Jan 2013)
New Revision: 25807

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-01-17 00:53:11 UTC (rev 25806)
+++ gnunet-java/ISSUES  2013-01-17 00:55:58 UTC (rev 25807)
@@ -1,3 +1,4 @@
+
 == meeting January 3, 2013 ==
 
 * https://gnunet.org/bugs/view.php?id=2720
@@ -56,3 +57,78 @@
 
 * GNUNET_APPLICATION_TYPE_END obvious, but not documented -- eh, it is.
 
+
+-----------------------------------------------------------------
+
+== Meeting January 10 ==
+
+
+* 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?
+ 
+