# Design a Streaming TLV Message Reassembler in C Design a C implementation that consumes a stream of 32-bit packets belonging to multiple messages. The packet format is type-length-value based and includes finite-width message and packet identifiers. Packets for one message may arrive out of order. Across the packets, the stream carries file data and metadata needed to produce the completed message as a file with the correct file name and permissions. The exact bit allocation, TLV type values, and completion marker are supplied by the packet specification during the interview; they are not reproduced here. Explain how your parser derives masks and bounds from that specification rather than guessing them. Cover parsing, fixed-size indexing, out-of-order storage, duplicate handling, completion, secure file creation, cleanup, and error reporting. ### Constraints & Assumptions - Use C and treat every incoming 32-bit word as untrusted input. - Message and packet ID widths are finite, so direct-indexed arrays are available; justify when their memory cost is acceptable. - Packets can be duplicated, malformed, delayed, or delivered out of order. - A message must not be published until the parser has all required data and validated file metadata. - The design must state which specification field proves completeness; without a packet count, total length, or end marker, completion cannot be determined reliably. ### Clarifying Questions to Ask - What is the exact bit layout and byte order of each packet header and TLV value? - How are payload bytes represented when the transport unit is 32 bits? - Which field supplies total packet count or message length, and may that metadata arrive late? - Are duplicate packets guaranteed identical, and what should happen if they conflict? - What characters, path components, and permission bits are valid for the output file? - How many incomplete messages and buffered bytes may exist at once, and when should stale state expire? ```hint Index by bounded identifiers If the protocol gives small fixed-width IDs, an array plus a received bitmap can make lookup and duplicate detection constant time. ``` ```hint Publish atomically Assemble into a protected temporary file or buffer, validate completeness and metadata, then make the final name visible in one controlled step. ``` ### What a Strong Answer Covers - Unsigned parsing with explicit byte-order conversion, masks, shifts, length checks, and no reliance on C bit-field layout. - Fixed-size message slots and per-message packet slots or bitmaps derived from protocol widths, with explicit memory bounds. - State for file metadata, expected packet or byte count, received fragments, duplicates, conflicts, and last activity. - Correct reassembly when metadata and data arrive in any order, plus a completion predicate grounded in the supplied protocol. - Safe file-name validation, restricted permission handling, temporary-file assembly, `fchmod`, durable close, and atomic rename. - Cleanup for malformed or expired messages, allocation and integer-overflow checks, concurrency control, and precise status codes. - Complexity and an explanation of when direct indexing should be replaced by a sparse structure. ### Follow-up Questions 1. How would you handle two packets with the same message and packet IDs but different contents? 2. What changes if the identifier widths make a full direct-indexed array too large? 3. How do you prevent a malicious file name from escaping the output directory? 4. Can fragments be written directly to disk before earlier packets arrive? 5. How would multiple producer threads feed the parser safely without one global lock?