gnunet/src/transport/NOTES

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!