1 This file lists minor work items (also possibly called "known bugs").
2 We are not tracking them in Mantis yet since there are too many and no
3 sane end-user should care about this codebase yet anyway.
7 - only connect() sockets that are ready (select()) [Nils]
8 [On W32, we need to select after calling socket before
11 - implement transport API to pretty-print transport address
12 + transport_api extension (API extension!)
13 + service-transport extension (protocol extension)
14 - add calls to statistics in various places
15 - implement gnunet-transport (transport configurator / tester)
16 - UPnP-based IP detection
17 (Note: build library always, build service when libxml2/etc. are available)
18 - instantly filter addresses from *other* peers that
19 are *equal* to our own address + port (i.e., localhost:2086). We
20 no longer filter those for outgoing (helps with loopback testing
21 and keeps the code clean), but we should filter strictly *impossible*
22 incoming addresses! This is for efficiency, not correctness.
23 - We currently are happy to take any address told to us in a WELCOME
24 to our set of addresses; we should have some minimal threshold-based
25 scheme, limiting both the total number of addresses that we accept
26 this way as well as requiring multiple confirmations; also, we
27 should possibly try to confirm that the given address works for
28 us ourselves (loopback-style) before adding it to the list
30 + we may be able to simplify WELCOME messages (no need to add
31 addresses there anymore, but may help to learn them there anyway...).
32 + we probably want some kind of voting/counting for learning IP addresses
33 (maybe including IP addresses in ads proportional to how often others
34 report them? we at least need some protection against >64k HELLOs!),
35 + provide a way to give the user a list of "learned" IP addresses and
36 a way to easily "veto" addresses off the list!
37 => If MiM attacker uses vetoed address, blacklist the specific IP for
38 the presumed neighbour!
39 - not sure current way of doing ACKs works well-enough
40 with unreliable transports where the ACK maybe lost;
41 the "is_new" check would then possibly prevent future
42 ACKs to be delivered, all while we're happily
43 receiving messages from that peer! Worse, the other
44 peer won't generate another ACK since it thinks we're
45 connected just fine...
47 + How necessary is ACKing in the first place? (alternatives?)
48 + Should we transmit ACKs in response to every HELLO? (would that
49 fully address the problem?)
50 - [./transport/gnunet-service-transport.c:173]: (style) struct or union member 'TransportPlugin::rebuild' is never used
51 - [./transport/plugin_transport_tcp.c:391]: (style) struct or union member 'Plugin::address_update_task' is never used
53 - [./fs/gnunet-service-fs.c:208]: (style) struct or union member 'LocalGetContext::results_bf_size' is never used
54 - [./fs/gnunet-service-fs.c:501]: (style) struct or union member 'PendingRequest::used_pids_size' is never used
55 - [./fs/gnunet-service-fs.c:654]: (style) struct or union member 'ConnectedPeer::last_client_replies' is never used
56 - [./fs/gnunet-service-fs.c:669]: (style) struct or union member 'ConnectedPeer::avg_delay' is never used
57 - [./fs/gnunet-service-fs.c:675]: (style) struct or union member 'ConnectedPeer::avg_priority' is never used
58 - [./fs/gnunet-service-fs.c:688]: (style) struct or union member 'ConnectedPeer::pending_requests' is never used
59 - [./fs/gnunet-service-fs.c:694]: (style) struct or union member 'ConnectedPeer::last_p2p_replies_woff' is never used
60 - [./fs/gnunet-service-fs.c:700]: (style) struct or union member 'ConnectedPeer::last_client_replies_woff' is never used
62 - If the topology daemon crashes, peers that were put on the
63 blacklist with transport will never be removed from it (until
64 transport service dies); we should use the blacklist notification
65 API to learn about the exact set of blacklisted peers at all times
66 (FIXME: the transport_api implementation of blacklisting
67 also does not work nicely for this since it won't let us know about
68 disconnect-reconnect events and the implicit whitelisting
69 that might happen here; that's not so bad since we will
70 re-blacklist on pre-connect attempts anyway, so this is
72 - the code uses the term 'blacklist' for both peers that are forbidden
73 to connect (i.e. F2F mode) as well as peers that we currently
74 won't try to actively connect to ourselves (since we just tried);
75 This is confusing. We need two distinct terms.
76 - move code to use hash table instead of linked list
77 - instead of periodically discarding blacklisted entries,
78 simply add task that is triggered at the right time (earlier free,
80 - check if new HELLO learned is different from old HELLO
81 before resetting entire state!
83 - auto-generate "defaults.conf" using gnunet-setup from "config.scm"
84 - integrate all options into "config.scm"
85 - change config-file writing to exclude options set to default values
87 - implement exponential back-off for service restarts
88 - better tracking of which config changes actually need to cause process restarts by ARM.
89 - have way to specify dependencies between services (to manage ARM restarts better)
91 - test case (test_core_api) hangs for a while (some timeout task not killed somewhere?)
92 - [./core/gnunet-service-core.c:469]: (style) struct or union member 'Neighbour::message_queue_size' is never used
93 - [./core/test_core_api_start_only.c:50]: (style) struct or union member 'PeerContext::id' is never used
96 - Better SSL-support for MHD
99 - active reply route caching design & implementation of service,
102 - consider changing API for peer-group termination to
103 call continuation when done
106 - 'server' uses 'GNUNET_PEERINFO_iterate', should probably switch to notification API
107 (for more instant / up-to-date hostlists at lower cost) [OPTIMIZATION]