gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] r10338 - gnunet


From: gnunet
Subject: [GNUnet-SVN] r10338 - gnunet
Date: Tue, 16 Feb 2010 23:34:35 +0100

Author: grothoff
Date: 2010-02-16 23:34:35 +0100 (Tue, 16 Feb 2010)
New Revision: 10338

Modified:
   gnunet/BUGS
Log:
done

Modified: gnunet/BUGS
===================================================================
--- gnunet/BUGS 2010-02-16 22:34:20 UTC (rev 10337)
+++ gnunet/BUGS 2010-02-16 22:34:35 UTC (rev 10338)
@@ -36,17 +36,6 @@
       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?)
   - [./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:
@@ -90,11 +79,6 @@
   - better crash management (attach debugging support, capture and analyze
     debug output, detect random vs. deterministic crashes)
   - shutdown sequence?
-* CORE: 
-  - 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
-
 * HTTPS transport
   - Better SSL-support for MHD
   - https integration





reply via email to

[Prev in Thread] Current Thread [Next in Thread]