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:
swaitsandClaude Opus 4.7 committed 2026-05-12 09:25:19 -06:00
1 parent c0f9c22efd
commit 3a8918fb0e
1 file changed
+7 -1
+7 -1
View File
@@ -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