nik/bitchat-android
1
0
Fork 0
mirror of https://github.com/permissionlesstech/bitchat-android.git synced 2026-10-18 07:33:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Correct the TLV header doc on the type it describes

Browse Source 
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.
This commit is contained in:
Taksh 2026-08-16 09:45:12 +05:30
parent 61fa6ee9cb
commit fd55a7d8e8
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
app/src/main/java/com/bitchat/android/model/BitchatFilePacket.kt
View File

@ -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