[On W32, we need to select after calling socket before
doing connect etc.]
* TRANSPORT:
- - transport_api: support forcing disconnects through low quotas!
- (required for working F2F support!)
- - API: consider having core provide deadline information for each message
- (likely important for DV plugin which wants to loop back!)
- implement transport API to pretty-print transport address
+ transport_api extension (API extension!)
+ service-transport extension (protocol extension)
+ How necessary is ACKing in the first place? (alternatives?)
+ Should we transmit ACKs in response to every HELLO? (would that
fully address the problem?)
- - latency measurements implemented in the transport
- plugins makes it only work for bi-di transports
- and results in code replication
- - should latency be included in the ReceiveCallback and
- NotifyConnect or passed on request?
- - FIXME's with latency being simply set to 0 in a few places
- [./transport/gnunet-service-transport.c:173]: (style) struct or union member 'TransportPlugin::rebuild' is never used
- [./transport/plugin_transport_tcp.c:391]: (style) struct or union member 'Plugin::address_update_task' is never used
-
* FS:
- [./fs/gnunet-service-fs.c:208]: (style) struct or union member 'LocalGetContext::results_bf_size' is never used
- [./fs/gnunet-service-fs.c:501]: (style) struct or union member 'PendingRequest::used_pids_size' is never used
- [./fs/gnunet-service-fs.c:688]: (style) struct or union member 'ConnectedPeer::pending_requests' is never used
- [./fs/gnunet-service-fs.c:694]: (style) struct or union member 'ConnectedPeer::last_p2p_replies_woff' is never used
- [./fs/gnunet-service-fs.c:700]: (style) struct or union member 'ConnectedPeer::last_client_replies_woff' is never used
-
* TOPOLOGY:
- - [./topology/gnunet-daemon-topology.c:94]: (style) struct or union member 'PeerList::last_hello_sent' is never used
-
+ - If the topology daemon crashes, peers that were put on the
+ blacklist with transport will never be removed from it (until
+ transport service dies); we should use the blacklist notification
+ API to learn about the exact set of blacklisted peers at all times
+ (FIXME: the transport_api implementation of blacklisting
+ also does not work nicely for this since it won't let us know about
+ disconnect-reconnect events and the implicit whitelisting
+ that might happen here; that's not so bad since we will
+ re-blacklist on pre-connect attempts anyway, so this is
+ a minor issue).
+ - the code uses the term 'blacklist' for both peers that are forbidden
+ to connect (i.e. F2F mode) as well as peers that we currently
+ won't try to actively connect to ourselves (since we just tried);
+ This is confusing. We need two distinct terms.
+ - move code to use hash table instead of linked list
+ - instead of periodically discarding blacklisted entries,
+ simply add task that is triggered at the right time (earlier free,
+ more balanced load)
+ - check if new HELLO learned is different from old HELLO
+ before resetting entire state!
* SETUP:
- auto-generate "defaults.conf" using gnunet-setup from "config.scm"
- integrate all options into "config.scm"