commit 360cede2f64bfe98f9587795211605fb02d859dd
parent 95da98bf28e4c1a35ab3c873333291e5551bb4cc
Author: Pedram Fardzadeh <p.fardzadeh@protonmail.com>
Date: Sat, 25 May 2024 18:26:13 +0200
Rephrased UDP Communicators second part
Diffstat:
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -218,18 +218,18 @@
high-volume data transfer because a new key exchange is conducted for every packet.
</t>
<t>
- Should however the target peer acknowledge the reception of a KX packet the resulting key can be re-used.
- Such an ACK packet can be either send via a bi-directional UDP connection or a backchannel connection provided
- by TRANSPORT. The wire format for such an KX packet is depicted in <xref target="figure_udp_ack"/>.
- This will cause the communicator to offer a new queue (with a higher priority than the default queue) to
- TRANSPORT with a limited capacity. The capacity is increased whenever the communicator receives an ACK for a
- transmission. This queue is suitable for high-volume data transfer and TRANSPORT will prioritize this queue
- if available.
+ If the target peer acknowledges the reception of a KX packet, the resulting key can be reused. Such an ACK
+ packet can be sent either via a bi-directional UDP connection or a backchannel connection provided by
+ TRANSPORT. The wire format for an ACK packet is depicted in <xref target="figure_udp_ack"/>.
+ This acknowledgment prompts the communicator to offer a new queue to TRANSPORT, which has a higher priority
+ than the default queue but starts with limited capacity. The capacity increases whenever the communicator
+ receives an ACK for a transmission. This queue is suitable for high-volume data transfer, and TRANSPORT
+ will prioritize it if available.
</t>
<t>
- The initiating communicator tries to authenticate their peer ID (public key) in the first packets by signing
- a monotonic time stamp, its peer ID, and the target peerID and send this data as well as the signature in
- one of the first packets. Receivers should keep track (persist) of the monotonic time stamps for each
+ The initiating communicator attempts to authenticate its peer ID (public key) in the initial packets by signing
+ a monotonic time stamp, its peer ID, and the target peerID. This signed data, along with the signature, is sent
+ in one of the first packets. Receivers should keep track (persist) of the monotonic time stamps for each
peer ID to reject possible replay attacks.
</t>
