From 0fe0ef0d87a30cdf78f89a5ae71cead8d3b390e3 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 9 Jun 2019 18:48:48 +0200 Subject: 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" -- cgit v1.2.3