[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [gnunet] branch master updated: update todo on FC: might be
[GNUnet-SVN] [gnunet] branch master updated: update todo on FC: might be finished (in theory)
Sun, 09 Jun 2019 18:49:33 +0200
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
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
index ce16c1541..18a80b3c5 100644
@@ -24,20 +24,6 @@
* 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
- * 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
|[Prev in Thread]
||[Next in Thread]|
- [GNUnet-SVN] [gnunet] branch master updated: update todo on FC: might be finished (in theory),