diff options
Diffstat (limited to 'src/transport/NOTES')
-rw-r--r-- | src/transport/NOTES | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/src/transport/NOTES b/src/transport/NOTES new file mode 100644 index 000000000..41404e1f9 --- /dev/null +++ b/src/transport/NOTES | |||
@@ -0,0 +1,46 @@ | |||
1 | KEY DESIGN CHOICES: | ||
2 | - who decides which connections to keep/create? | ||
3 | => higher level session/key management! | ||
4 | - who enforces things like F2F topology, etc? | ||
5 | => higher level session/key management! | ||
6 | - who tracks all known HELLOs & validates? | ||
7 | => We validate, PEERINFO tracks! | ||
8 | - who advertises our HELLO? | ||
9 | => us! (need background job; previously: advertising) | ||
10 | - who advertises other peers HELLOs? | ||
11 | => higher level (core?) | ||
12 | - who does bootstrapping? | ||
13 | => bootstrap service (external!) | ||
14 | - who enforces inbound bandwidth limits? | ||
15 | => transport-service and plugins! (previously: core); | ||
16 | either by limiting reads (TCP) or discarding packets | ||
17 | (transport-service) | ||
18 | - who enforces outbound bandwidth limits? | ||
19 | => transport_api! | ||
20 | - who decides outbound bandwidth limits? | ||
21 | => other peer, via core (need authenticated limits!) | ||
22 | - who decides inbound bandwidth limits? | ||
23 | => core / apps above core (need trust info) | ||
24 | - cost function for transports is latency estimate in ms | ||
25 | => plugin provides latency data, transport-service | ||
26 | selects plugin(s) for transmission | ||
27 | - who is responsible for fragmentation? | ||
28 | => plugins! (may use common shared library) | ||
29 | - should we require UDP to be reliable? | ||
30 | => NO. There are other places that may (rarely) | ||
31 | use messages that we can not fix | ||
32 | - how do we access the 50% of service that we need for TCP/UDP | ||
33 | from service.c without code replication or getting 50% | ||
34 | that we do not want (i.e. shutdown, pid-file-writing, etc.) | ||
35 | => use GNUNET_SERVICE_start/stop functions! | ||
36 | - At what level do we manage timeouts? | ||
37 | => At the plugin (TCP connections), | ||
38 | transport-service (neighbours) and | ||
39 | core (sessions) level! | ||
40 | => All plugins have to disconnect before service-level | ||
41 | disconnect occurs | ||
42 | => We can have a plugin-connection die, but the session | ||
43 | survives! | ||
44 | => We can have a session die (no further authenticated | ||
45 | communication) even if the plugin thinks it is still | ||
46 | up! | ||