[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [gnunet] 01/02: update TODOs
From: |
gnunet |
Subject: |
[GNUnet-SVN] [gnunet] 01/02: update TODOs |
Date: |
Sun, 12 May 2019 16:14:49 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository gnunet.
commit 373d4a33f361b18de61c319287950d4d349ed48b
Author: Christian Grothoff <address@hidden>
AuthorDate: Sun May 12 15:58:26 2019 +0200
update TODOs
---
src/transport/gnunet-service-tng.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/transport/gnunet-service-tng.c
b/src/transport/gnunet-service-tng.c
index 59575da79..4e8947237 100644
--- a/src/transport/gnunet-service-tng.c
+++ b/src/transport/gnunet-service-tng.c
@@ -40,7 +40,7 @@
* whatever else we could reach.
* - AcknowledgementUUIDPs are overkill with 256 bits (128 would do)
* => Need 128 bit hash map though! [BANDWIDTH, MEMORY]
- * - queue_send_msg and route_message both by API design have to make copies
+ * - queue_send_msg by API design has to make a copy
* of the payload, and route_message on top of that requires a malloc/free.
* Change design to approximate "zero" copy better... [CPU]
* - could avoid copying body of message into each fragment and keep
@@ -56,6 +56,10 @@
* triggering an explicit validation mechansim ourselves, specifically
routing
* a challenge-response message over the path [ROUTING]
* - Track ACK losses based on ACK-counter [ROUTING]
+ * - Fragments send over a reliable channel could do without the
+ * AcknowledgementUUIDP altogether, as they won't be acked! [BANDWIDTH]
+ * (-> have 2nd type of acknowledgment message; low priority, as we
+ * do not have an MTU-limited *reliable* communicator)
*
* Design realizations / discussion:
* - communicators do flow control by calling MQ "notify sent"
--
To stop receiving notification emails like this one, please contact
address@hidden