From fd55a7d8e8def690b79a8b90a548eac574941734 Mon Sep 17 00:00:00 2001 From: Taksh Date: Sun, 16 Aug 2026 09:45:12 +0530 Subject: [PATCH] Correct the TLV header doc on the type it describes The class doc described neither what encode writes nor what decode reads: it claimed 2-byte lengths for every TLV and an 8-byte FILE_SIZE, where the code uses 4 bytes for both CONTENT and FILE_SIZE, and it presented multi-TLV chunking as the way large files are carried when v2 writes exactly one CONTENT TLV and fragments at the transport layer. docs/file_transfer.md already has this right. Bringing the doc on the type into line with it, and recording why the multi-TLV tolerance path has to stay linear, since that is what this branch changes. --- .../com/bitchat/android/model/BitchatFilePacket.kt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/app/src/main/java/com/bitchat/android/model/BitchatFilePacket.kt b/app/src/main/java/com/bitchat/android/model/BitchatFilePacket.kt index 0c01b05b..eaa38e7f 100644 --- a/app/src/main/java/com/bitchat/android/model/BitchatFilePacket.kt +++ b/app/src/main/java/com/bitchat/android/model/BitchatFilePacket.kt @@ -7,12 +7,17 @@ import java.nio.ByteOrder * BitchatFilePacket: TLV-encoded file transfer payload for BLE mesh. * TLVs: * - 0x01: filename (UTF-8) - * - 0x02: file size (8 bytes, UInt64) + * - 0x02: file size (4 bytes, UInt32) * - 0x03: mime type (UTF-8) - * - 0x04: content (bytes) — may appear multiple times for large files + * - 0x04: content (bytes) * - * Length field for TLV is 2 bytes (UInt16, big-endian) for all TLVs. - * For large files, CONTENT is chunked into multiple TLVs of up to 65535 bytes each. + * Length fields are 2 bytes (UInt16, big-endian), except CONTENT, which uses 4 bytes so a + * payload can exceed 64 KiB without TLV-level chunking. This matches `docs/file_transfer.md`; + * the previous text here described neither what `encode` writes nor what `decode` reads. + * + * v2 writes exactly one CONTENT TLV. `decode` still accepts several and concatenates them in + * order as defensive tolerance for legacy senders, but the chunk count is the sender's to + * choose, so that reassembly must stay linear in the payload rather than in chunks x bytes. * * Unknown TLV types are SKIPPED, not rejected: the tag list above is a floor, * not a ceiling, and a decoder that bails on the first tag it does not know