* UTIL:
- - container_bloomfilter: improve efficiency (see FIXME)
- - Windows: use events instead of pipes to signal select()s [Nils]
- only connect() sockets that are ready (select()) [Nils]
[On W32, we need to select after calling socket before
doing connect etc.]
- - server: inefficient memmove
- - client: should do exponential back-off (starting at 1ms,
- bounded by 1s) when connection failed (in addition to
- half-time-to-deadline retry at the end)
* 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)
a way to easily "veto" addresses off the list!
=> If MiM attacker uses vetoed address, blacklist the specific IP for
the presumed neighbour!
- - not sure current way of doing ACKs works well-enough
- with unreliable transports where the ACK maybe lost;
- the "is_new" check would then possibly prevent future
- ACKs to be delivered, all while we're happily
- receiving messages from that peer! Worse, the other
- peer won't generate another ACK since it thinks we're
- connected just fine...
- Key questions:
- + 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
- - Memory leak (running valgrind --trace-children=yes on test_transport_api:
- ==28393== 16 bytes in 1 blocks are indirectly lost in loss record 1 of 5
- ==28393== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
- ==28393== by 0x52343E3: GNUNET_xmalloc_unchecked_ (common_allocation.c:62)
- ==28393== by 0x5234389: GNUNET_xmalloc_ (common_allocation.c:53)
- ==28393== by 0x524458A: GNUNET_NETWORK_socket_create_from_accept (network.c:289)
- ==28393== by 0x524B2DA: ??? (server.c:332)
- ==28393== by 0x524A4C7: ??? (scheduler.c:425)
- ==28393== by 0x524A73D: GNUNET_SCHEDULER_run (scheduler.c:510)
- ==28393== by 0x524FF8C: GNUNET_SERVICE_run (service.c:1326)
- ==28393== by 0x405500: main (gnunet-service-transport.c:2645)
- And also:
- ==28393== 65,744 (65,728 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
- ==28393== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
- ==28393== by 0x52343E3: GNUNET_xmalloc_unchecked_ (common_allocation.c:62)
- ==28393== by 0x5234389: GNUNET_xmalloc_ (common_allocation.c:53)
- ==28393== by 0x524473E: GNUNET_NETWORK_socket_create_from_accept (network.c:323)
- (rest of trace identical)
-
- [./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
- - while running the topology test with valgrind (--trace-children=yes), I get:
-
-Nov 03 22:38:57 topology DEBUG I am peer `AJ5M'==4186== Syscall param socketcall.send(msg) points to uninitialised byte(s)
-==4186== at 0x4164BF1: send (socket.S:64)
-==4186== by 0x404CC1F: transmit_ready (connection.c:1393)
-==4186== by 0x4063C3B: run_ready (scheduler.c:451)
-==4186== by 0x40640AE: GNUNET_SCHEDULER_run (scheduler.c:575)
-==4186== by 0x406090A: GNUNET_PROGRAM_run (program.c:196)
-==4186== by 0x804B1CA: main (gnunet-daemon-topology.c:1250)
-==4186== Address 0x46e33b0 is 136 bytes inside a block of size 65,664 alloc'd
-==4186== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
-==4186== by 0x40476F6: GNUNET_xmalloc_unchecked_ (common_allocation.c:61)
-==4186== by 0x404768E: GNUNET_xmalloc_ (common_allocation.c:52)
-==4186== by 0x404BB22: GNUNET_CONNECTION_create_from_connect (connection.c:887)
-==4186== by 0x40460B8: do_connect (client.c:233)
-==4186== by 0x404610C: GNUNET_CLIENT_connect (client.c:259)
-==4186== by 0x402C6D5: GNUNET_CORE_connect (core_api.c:857)
-==4186== by 0x804B118: run (gnunet-daemon-topology.c:1217)
-==4186== by 0x4060498: program_main (program.c:80)
-==4186== by 0x4063C3B: run_ready (scheduler.c:451)
-==4186== by 0x40640AE: GNUNET_SCHEDULER_run (scheduler.c:575)
-==4186== by 0x406090A: GNUNET_PROGRAM_run (program.c:196)
-==4186==
-
-
-* DATASTORE:
- - mysql backend
- - postgres backend
+ - 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"
- change config-file writing to exclude options set to default values
* ARM:
- - implement exponential back-off for service restarts
- better tracking of which config changes actually need to cause process restarts by ARM.
- - have way to specify dependencies between services (to manage ARM restarts better)
-* CORE:
- - code currently notifies clients about "encrypted" connections being up well before
- we get the encrypted PONG; sometimes this may be OK (for topology killing
- unwanted connnections), but of course not in general. I suspect we want
- to signal on PONG and have topology hook directly into transport to
- kill plaintext connections before they have a chance to become encrypted
- (may require minor hack in transport API)
- - [./core/gnunet-service-core.c:469]: (style) struct or union member 'Neighbour::message_queue_size' is never used
- - [./core/test_core_api_start_only.c:50]: (style) struct or union member 'PeerContext::id' is never used
-
-* PEERINFO:
- - have gnunet-peerinfo print actual host addresses again
- - add option to gnunet-peerinfo to modify trust value
-* POSTGRES-DB:
- - finish postgres implementation; simplify other SQLs using new stats
+ - listen for requests to discover dependencies between services (and avoid
+ having to explicitly program start requests)
+ - better crash management (attach debugging support, capture and analyze
+ debug output, detect random vs. deterministic crashes)
+ - shutdown sequence?
* HTTPS transport
- Better SSL-support for MHD
- https integration
* GAP improvements:
- active reply route caching design & implementation of service,
gap extension!
-* HOSTLIST:
- - implement advertising of hostlist URL
- - implement learning of hostlist URLs
* TESTING:
- consider changing API for peer-group termination to
call continuation when done
+
+* HOSTLIST:
+ - 'server' uses 'GNUNET_PEERINFO_iterate', should probably switch to notification API
+ (for more instant / up-to-date hostlists at lower cost) [OPTIMIZATION]
projects / oweals / gnunet.git / blobdiff