1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
== meeting January 3, 2013 ==
* https://gnunet.org/bugs/view.php?id=2720
* had no idea where to look for this
* non-deterministic
* "pkill -9 gnunet" gets annoying ;)
* rounds:
1. every peer broadcasts its set difference estimator
2. every peer responds to incoming difference estimators with its ibf of appropriate size
* but max. one response per round per other peer
* should we do this naively, or coalesce them as much as possible?
3. every peer responds to the IBF with the actual elements (not hashes) that only he has,
as well as a list of hashes, where he needs the actual elements.
4. every peer receives the actual elements, and element requests, sends missing elements of the other peer
5. every peer receives the rest of the missing elements
* => naive implementation doubles the work (as every peer pair sends/receives one estimator respectively),
any way to make the protocol better w.r.t. this?
* how do we determine the time for one round?
* how reliable of an indicator is an empty strata estimator?
* bad, when we have large sets, there will always be overflows in the high frequency strata
* benchmarks / measurements of quality for consensus
* how do we judge the quality of consensus implementation for challenging situations?
* GNUNET_MESH_peer_request_connect_add, can it fail, how can it fail, what is the timeout (see docs)?
* in mesh, tunnels are two-way. each peer has a broadcast tunnel, and incoming tunnels from other peers.
* now there are two ways to send a message to another peer, which of the tunnels is preferable / does is even matter?
* i.e., is there a performance difference in to-origin vs. unicast?
* the number of possible groups is very large, shouldn't we restrict their number?
* shouldn't we introduce this as another parameter for conclude?
* assume every peer in our session is either muted or in agreement, how do we proceed with generating the groups?
* how do we generate/rank the groups?
* interpretation of infinity as timeout for conclude: only stop exchaning once we have perfect consensus
* what is there to say about broadcast performance in gerneral?
* bart talked about NSE style broadcast, what is this?
* Jan 02 22:03:52-356968 core-api-22511 INFO (Re)connecting to CORE service, monitoring messages of type 0
* how does that make sense?
* IBF hash function: there's no need to have a cryptographic hash, as no randomization is possible,
and the domain of the hash function actually is really small. To find one collision on an IBF with n buckets, on average
we only have to try n random values, there's no need to find a SHA-256 collision
* when the client violates the protocol, what should the service do?
* most services use GNUNET_break?
* which is not very helful, as developers for other bindings (e.g. java ;) have to look up the right line in the c code,
with no error message
* GNUNET_APPLICATION_TYPE_END obvious, but not documented
|
