X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=BUGS;h=1d9398c9b2ad2a582f3f36bc3abd1be51952ca32;hb=4a091fe51761db20dea1a3325dfff89209e907b4;hp=504ff2c210bcce518db16646d15c9d4b3559a35e;hpb=cf45b8dff29c366d51aa2e6ea6a64b99b514b9c9;p=oweals%2Fgnunet.git diff --git a/BUGS b/BUGS index 504ff2c21..1d9398c9b 100644 --- a/BUGS +++ b/BUGS @@ -2,26 +2,12 @@ This file lists minor work items (also possibly called "known bugs"). We are not tracking them in Mantis yet since there are too many and no sane end-user should care about this codebase yet anyway. -* TESTING: - - connection.c:553 fails when "make check" is run! - (check if this could be memory corruption). - * 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) @@ -61,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 @@ -98,37 +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 - - 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" @@ -138,29 +88,20 @@ Nov 03 22:38:57 topology DEBUG I am peer `AJ5M'==4186== Syscall param socketcall - 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]