gnunet-svn
[Top][All Lists]
Advanced

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

[GNUnet-SVN] [gnunet] 01/02: notes


From: gnunet
Subject: [GNUnet-SVN] [gnunet] 01/02: notes
Date: Sat, 23 Feb 2019 10:48:30 +0100

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository gnunet.

commit 3d0f1dd3805bfef30ff7a7f8e246a926b7fa7838
Author: Christian Grothoff <address@hidden>
AuthorDate: Sat Feb 23 10:47:41 2019 +0100

    notes
---
 src/transport/gnunet-service-tng.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/src/transport/gnunet-service-tng.c 
b/src/transport/gnunet-service-tng.c
index a32d1872c..d392b3a46 100644
--- a/src/transport/gnunet-service-tng.c
+++ b/src/transport/gnunet-service-tng.c
@@ -33,6 +33,19 @@
  *       transport-to-transport traffic)
  *
  * Implement next:
+ * - address validation: what is our plan here?
+ *   #1 Peerstore only gets 'validated' addresses
+ *   #2 transport needs another API to "trigger" validation!
+ *      API may be used by core/application or communicators;
+ *      => use yet another lib/MQ/connection?
+ *   #3 transport should use validation to also establish
+ *      effective flow control (for uni-directional transports!)
+ *   #4 UDP broadcasting logic must be extended to use the new API
+ *   #5 only validated addresses go to ATS for scheduling; that
+ *      also ensures we know the RTT 
+ *   #6 to ensure flow control and RTT are OK, we always do the
+ *      'validation', even if address comes from PEERSTORE
+ *   #7 
  * - ACK handling / retransmission 
  * - track RTT, distance, loss, etc.
  * - DV data structures:

-- 
To stop receiving notification emails like this one, please contact
address@hidden



reply via email to

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