summaryrefslogtreecommitdiff
path: root/src/transport/gnunet-service-tng.c
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2019-05-12 15:58:26 +0200
committerChristian Grothoff <christian@grothoff.org>2019-05-12 15:58:26 +0200
commit373d4a33f361b18de61c319287950d4d349ed48b (patch)
tree1c75571c5037e4df192e01a36ba05c5ef7dd8ab4 /src/transport/gnunet-service-tng.c
parent3bc24eed4502122bee2e7a8d49b1afcca51ce438 (diff)
update TODOs
Diffstat (limited to 'src/transport/gnunet-service-tng.c')
-rw-r--r--src/transport/gnunet-service-tng.c6
1 files changed, 5 insertions, 1 deletions
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"