[GNUnet-SVN] [gnunet] branch master updated: update todo on FC: might be finished (in theory)

[gnunet]

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

grothoff pushed a commit to branch master
in repository gnunet.

The following commit(s) were added to refs/heads/master by this push:
     new 0fe0ef0d8 update todo on FC: might be finished (in theory)
0fe0ef0d8 is described below

commit 0fe0ef0d87a30cdf78f89a5ae71cead8d3b390e3
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun Jun 9 18:48:48 2019 +0200

    update todo on FC: might be finished (in theory)
---
 src/transport/gnunet-service-tng.c | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/src/transport/gnunet-service-tng.c 
b/src/transport/gnunet-service-tng.c
index ce16c1541..18a80b3c5 100644
--- a/src/transport/gnunet-service-tng.c
+++ b/src/transport/gnunet-service-tng.c
@@ -24,20 +24,6 @@
  *
  * TODO:
  * Implement next:
- * - FIXME-FC: realize transport-to-transport flow control (needed in case
- *   communicators do not offer flow control).
- *   We do transmit FC window sizes now.
- *
- *   for DV)
- *   - send challenges via DV (when DVH is confirmed *and* we care about
- *     the target to get window size, or when DVH is unconfirmed (passive
- *     learning!) to confirm it!)
- *   - handle challenge responses in this case (note: validity period of 
addresses
- *     will be zero!)
- *   - if available, try to use DV paths when trying to establish
- *     virtual link for a `struct IncomingRequest`. (i.e. if DVH is
- *     unconfirmed, incoming requests also trigger challenge-via-DV!)
- *
  * - review retransmission logic, right now there is no smartness there!
  *   => congestion control, etc [PERFORMANCE-BASICS]
  *
@@ -76,6 +62,10 @@
  * - Need to track total bandwidth per VirtualLink and adjust how frequently
  *   we send FC messages based on bandwidth-delay-product (and relation
  *   to the window size!). See OPTIMIZE-FC-BDP.
+ * - if available, try to confirm unconfirmed DV paths when trying to establish
+ *   virtual link for a `struct IncomingRequest`. (i.e. if DVH is
+ *   unconfirmed, incoming requests cause us to try to validate a passively
+ *   learned path (requires new message type!))
  *
  * Design realizations / discussion:
  * - communicators do flow control by calling MQ "notify sent"

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