diff options
author | Christian Grothoff <christian@grothoff.org> | 2019-04-21 13:29:37 +0200 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2019-04-21 13:29:37 +0200 |
commit | 196435205b803f01976560037c69553ac0e8e307 (patch) | |
tree | 69602aba60348770876628dc0c6433a9d7803ebd /src/transport/gnunet-service-tng.c | |
parent | d97224045fe41e824406f771e24c46fb89514942 (diff) | |
download | gnunet-196435205b803f01976560037c69553ac0e8e307.tar.gz gnunet-196435205b803f01976560037c69553ac0e8e307.zip |
reorder next steps
Diffstat (limited to 'src/transport/gnunet-service-tng.c')
-rw-r--r-- | src/transport/gnunet-service-tng.c | 63 |
1 files changed, 30 insertions, 33 deletions
diff --git a/src/transport/gnunet-service-tng.c b/src/transport/gnunet-service-tng.c index 697c43f0d..56ba70b9a 100644 --- a/src/transport/gnunet-service-tng.c +++ b/src/transport/gnunet-service-tng.c | |||
@@ -24,32 +24,23 @@ | |||
24 | * | 24 | * |
25 | * TODO: | 25 | * TODO: |
26 | * Implement next: | 26 | * Implement next: |
27 | * - retransmission logic | 27 | * - complete backchannel signature verification and |
28 | * forwarding of backchannel messages to communicators! | ||
28 | * - track RTT, distance, loss, etc. => requires extra data structures! | 29 | * - track RTT, distance, loss, etc. => requires extra data structures! |
29 | * | ||
30 | * Later: | ||
31 | * - change transport-core API to provide proper flow control in both | ||
32 | * directions, allow multiple messages per peer simultaneously (tag | ||
33 | * confirmations with unique message ID), and replace quota-out with | ||
34 | * proper flow control; | ||
35 | * - if messages are below MTU, consider adding ACKs and other stuff | ||
36 | * (requires planning at receiver, and additional MST-style demultiplex | ||
37 | * at receiver!) | ||
38 | * - could avoid copying body of message into each fragment and keep | ||
39 | * fragments as just pointers into the original message and only | ||
40 | * fully build fragments just before transmission (optimization, should | ||
41 | * reduce CPU and memory use) | ||
42 | * - When we passively learned DV (with unconfirmed freshness), we | ||
43 | * right now add the path to our list but with a zero path_valid_until | ||
44 | * time and only use it for unconfirmed routes. However, we could consider | ||
45 | * triggering an explicit validation mechansim ourselves, specifically routing | ||
46 | * a challenge-response message over the path (OPTIMIZATION-FIXME). | ||
47 | * | ||
48 | * FIXME (without marks in the code!): | ||
49 | * - proper use/initialization of timestamps in messages exchanged | 30 | * - proper use/initialization of timestamps in messages exchanged |
50 | * during DV learning | 31 | * during DV learning |
51 | * - persistence of monotonic time obtained from other peers | 32 | * - persistence of monotonic time obtained from other peers |
52 | * in PEERSTORE (by message type) | 33 | * in PEERSTORE (by message type) |
34 | * - change transport-core API to provide proper flow control in both | ||
35 | * directions, allow multiple messages per peer simultaneously (tag | ||
36 | * confirmations with unique message ID), and replace quota-out with | ||
37 | * proper flow control; specify transmission preferences (latency, | ||
38 | * reliability, etc.) per message! | ||
39 | * - add logging | ||
40 | * | ||
41 | * Later: | ||
42 | * - review retransmission logic, right now there is no smartness there! | ||
43 | * => congestion control, flow control, etc (requires RTT, loss, etc.) | ||
53 | * | 44 | * |
54 | * Optimizations: | 45 | * Optimizations: |
55 | * - use shorthashmap on msg_uuid's when matching reliability/fragment ACKs | 46 | * - use shorthashmap on msg_uuid's when matching reliability/fragment ACKs |
@@ -58,6 +49,18 @@ | |||
58 | * - queue_send_msg and route_message both by API design have to make copies | 49 | * - queue_send_msg and route_message both by API design have to make copies |
59 | * of the payload, and route_message on top of that requires a malloc/free. | 50 | * of the payload, and route_message on top of that requires a malloc/free. |
60 | * Change design to approximate "zero" copy better... | 51 | * Change design to approximate "zero" copy better... |
52 | * - could avoid copying body of message into each fragment and keep | ||
53 | * fragments as just pointers into the original message and only | ||
54 | * fully build fragments just before transmission (optimization, should | ||
55 | * reduce CPU and memory use) | ||
56 | * - if messages are below MTU, consider adding ACKs and other stuff | ||
57 | * (requires planning at receiver, and additional MST-style demultiplex | ||
58 | * at receiver!) | ||
59 | * - When we passively learned DV (with unconfirmed freshness), we | ||
60 | * right now add the path to our list but with a zero path_valid_until | ||
61 | * time and only use it for unconfirmed routes. However, we could consider | ||
62 | * triggering an explicit validation mechansim ourselves, specifically routing | ||
63 | * a challenge-response message over the path (OPTIMIZATION-FIXME). | ||
61 | * | 64 | * |
62 | * Design realizations / discussion: | 65 | * Design realizations / discussion: |
63 | * - communicators do flow control by calling MQ "notify sent" | 66 | * - communicators do flow control by calling MQ "notify sent" |
@@ -250,12 +253,9 @@ struct TransportBackchannelEncapsulationMessage | |||
250 | struct GNUNET_MessageHeader header; | 253 | struct GNUNET_MessageHeader header; |
251 | 254 | ||
252 | /** | 255 | /** |
253 | * Distance the backchannel message has traveled, to be updated at | 256 | * Reserved, always zero. |
254 | * each hop. Used to bound the number of hops in case a backchannel | ||
255 | * message is broadcast and thus travels without routing | ||
256 | * information (during initial backchannel discovery). | ||
257 | */ | 257 | */ |
258 | uint32_t distance; | 258 | uint32_t reserved GNUNET_PACKED; |
259 | 259 | ||
260 | /** | 260 | /** |
261 | * Target's peer identity (as backchannels may be transmitted | 261 | * Target's peer identity (as backchannels may be transmitted |
@@ -4260,8 +4260,8 @@ handle_fragment_box (void *cls, const struct TransportFragmentBox *fb) | |||
4260 | rc->frag_uuid = frag_uuid; | 4260 | rc->frag_uuid = frag_uuid; |
4261 | rc->num_acks++; | 4261 | rc->num_acks++; |
4262 | } | 4262 | } |
4263 | if (65 == rc->num_acks) /* FIXME: maybe use smaller threshold? This is very | 4263 | if (65 == rc->num_acks) /* OPTIMIZE-FIXME: maybe use smaller threshold? This |
4264 | aggressive. */ | 4264 | is very aggressive. */ |
4265 | ack_now = GNUNET_YES; /* maximum acks received */ | 4265 | ack_now = GNUNET_YES; /* maximum acks received */ |
4266 | // FIXME: possibly also ACK based on RTT (but for that we'd need to | 4266 | // FIXME: possibly also ACK based on RTT (but for that we'd need to |
4267 | // determine the queue used for the ACK first!) | 4267 | // determine the queue used for the ACK first!) |
@@ -4286,7 +4286,7 @@ handle_fragment_box (void *cls, const struct TransportFragmentBox *fb) | |||
4286 | /* successful reassembly */ | 4286 | /* successful reassembly */ |
4287 | send_fragment_ack (rc); | 4287 | send_fragment_ack (rc); |
4288 | demultiplex_with_cmc (cmc, msg); | 4288 | demultiplex_with_cmc (cmc, msg); |
4289 | /* FIXME: really free here? Might be bad if fragments are still | 4289 | /* FIXME-OPTIMIZE: really free here? Might be bad if fragments are still |
4290 | en-route and we forget that we finished this reassembly immediately! | 4290 | en-route and we forget that we finished this reassembly immediately! |
4291 | -> keep around until timeout? | 4291 | -> keep around until timeout? |
4292 | -> shorten timeout based on ACK? */ | 4292 | -> shorten timeout based on ACK? */ |
@@ -4449,7 +4449,7 @@ handle_reliability_box (void *cls, const struct TransportReliabilityBox *rb) | |||
4449 | { | 4449 | { |
4450 | struct TransportReliabilityAckMessage *ack; | 4450 | struct TransportReliabilityAckMessage *ack; |
4451 | 4451 | ||
4452 | /* FIXME: implement cummulative ACKs and ack_countdown, | 4452 | /* FIXME-OPTIMIZE: implement cummulative ACKs and ack_countdown, |
4453 | then setting the avg_ack_delay field below: */ | 4453 | then setting the avg_ack_delay field below: */ |
4454 | ack = GNUNET_malloc (sizeof (*ack) + sizeof (struct GNUNET_ShortHashCode)); | 4454 | ack = GNUNET_malloc (sizeof (*ack) + sizeof (struct GNUNET_ShortHashCode)); |
4455 | ack->header.type = htons (GNUNET_MESSAGE_TYPE_TRANSPORT_RELIABILITY_ACK); | 4455 | ack->header.type = htons (GNUNET_MESSAGE_TYPE_TRANSPORT_RELIABILITY_ACK); |
@@ -4592,9 +4592,6 @@ handle_backchannel_encapsulation ( | |||
4592 | if (0 != GNUNET_memcmp (&be->target, &GST_my_identity)) | 4592 | if (0 != GNUNET_memcmp (&be->target, &GST_my_identity)) |
4593 | { | 4593 | { |
4594 | /* not for me, try to route to target */ | 4594 | /* not for me, try to route to target */ |
4595 | /* FIXME: someone needs to update be->distance! */ | ||
4596 | /* FIXME: BE routing can be special, should we put all of this | ||
4597 | on 'route_message'? Maybe at least pass some more arguments? */ | ||
4598 | route_message (&be->target, | 4595 | route_message (&be->target, |
4599 | GNUNET_copy_message (&be->header), | 4596 | GNUNET_copy_message (&be->header), |
4600 | RMO_DV_ALLOWED); | 4597 | RMO_DV_ALLOWED); |