X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=BUGS;h=1d9398c9b2ad2a582f3f36bc3abd1be51952ca32;hb=4a091fe51761db20dea1a3325dfff89209e907b4;hp=7bb7e0cf5433b42c14e9aa37f0221e75bcee99db;hpb=d5128d1f3cbaf2e495ae1325b5c133cafca9437e;p=oweals%2Fgnunet.git diff --git a/BUGS b/BUGS index 7bb7e0cf5..1d9398c9b 100644 --- a/BUGS +++ b/BUGS @@ -4,20 +4,10 @@ sane end-user should care about this codebase yet anyway. * 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) @@ -57,34 +47,8 @@ sane end-user should care about this codebase yet anyway. + 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 @@ -94,13 +58,27 @@ sane end-user should care about this codebase yet anyway. - [./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 - -* 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" @@ -110,29 +88,20 @@ sane end-user should care about this codebase yet anyway. - 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) + - test case (test_core_api) hangs for a while (some timeout task not killed somewhere?) - [./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 * 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]