spec(multipart): document plain-ACK finalizer after MULTIPART chain
Clarify that the MULTIPART ACK chain terminates with a plain PAYLOAD_TYPE_ACK (not a MULTIPART with remaining=0). For K extra copies, the wire sequence is: MULTIPART(remaining=K), MULTIPART(remaining=K-1), ..., MULTIPART(remaining=1), then PAYLOAD_TYPE_ACK (plain). All copies share the same ack_crc. Receivers MUST dedup at the application layer by ack_crc, since each packet's hash differs. Validated against upstream meshcore-dev/MeshCore @ 1a7b361 (Mesh::routeDirectRecvAcks, src/Mesh.cpp:362 — while-loop emits MULTIPART(remaining=extra...1), then createAck(crc) plain ACK). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 file changed
+7
-1
@@ -57,7 +57,13 @@ The only currently defined multipart sub-type is ACK (sub_type = 0x03):
|
||||
Total payload: 5 bytes (1 byte header + 4 byte CRC).
|
||||
|
||||
Multipart ACKs are used to send additional ACK retransmissions for reliability.
|
||||
The `remaining` field indicates how many more ACK packets follow this one.
|
||||
The `remaining` field indicates how many more ACK packets follow this one,
|
||||
counting down: a chain of K extra copies is emitted as MULTIPART with
|
||||
`remaining = K, K-1, …, 1`, followed by exactly one final plain
|
||||
`PAYLOAD_TYPE_ACK` packet (NOT a MULTIPART with `remaining = 0`). All copies
|
||||
in the chain carry the same `ack_crc`. Receivers MUST treat the first copy
|
||||
received as the authoritative ACK and dedup subsequent copies by `ack_crc`
|
||||
at the application layer.
|
||||
|
||||
### Multipart ACK Usage Constraints
|
||||
|
||||
|
||||
Reference in new issue
Block a user