summaryrefslogtreecommitdiff
path: root/src/transport/NOTES
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2009-05-29 00:46:26 +0000
committerChristian Grothoff <christian@grothoff.org>2009-05-29 00:46:26 +0000
commit0a217a8df1657b4334b55b0e4a6c7837a8dbcfd9 (patch)
tree6b552f40eb089db96409a312a98d9b12bd669102 /src/transport/NOTES
ng
Diffstat (limited to 'src/transport/NOTES')
-rw-r--r--src/transport/NOTES46
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 @@
+KEY DESIGN CHOICES:
+ - who decides which connections to keep/create?
+ => higher level session/key management!
+ - who enforces things like F2F topology, etc?
+ => higher level session/key management!
+ - who tracks all known HELLOs & validates?
+ => We validate, PEERINFO tracks!
+ - who advertises our HELLO?
+ => us! (need background job; previously: advertising)
+ - who advertises other peers HELLOs?
+ => higher level (core?)
+ - who does bootstrapping?
+ => bootstrap service (external!)
+ - who enforces inbound bandwidth limits?
+ => transport-service and plugins! (previously: core);
+ either by limiting reads (TCP) or discarding packets
+ (transport-service)
+ - who enforces outbound bandwidth limits?
+ => transport_api!
+ - who decides outbound bandwidth limits?
+ => other peer, via core (need authenticated limits!)
+ - who decides inbound bandwidth limits?
+ => core / apps above core (need trust info)
+ - cost function for transports is latency estimate in ms
+ => plugin provides latency data, transport-service
+ selects plugin(s) for transmission
+ - who is responsible for fragmentation?
+ => plugins! (may use common shared library)
+ - should we require UDP to be reliable?
+ => NO. There are other places that may (rarely)
+ use messages that we can not fix
+ - how do we access the 50% of service that we need for TCP/UDP
+ from service.c without code replication or getting 50%
+ that we do not want (i.e. shutdown, pid-file-writing, etc.)
+ => use GNUNET_SERVICE_start/stop functions!
+ - At what level do we manage timeouts?
+ => At the plugin (TCP connections),
+ transport-service (neighbours) and
+ core (sessions) level!
+ => All plugins have to disconnect before service-level
+ disconnect occurs
+ => We can have a plugin-connection die, but the session
+ survives!
+ => We can have a session die (no further authenticated
+ communication) even if the plugin thinks it is still
+ up!