[GNUnet-SVN] [gnunet] 01/02: update TODOs

[gnunet]

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