Overview
The most challenging part of the ProcessWrapper is the UDP communication portion. Specifically facilitating for potential dropped and out of order packets, and the spanning of the order byte reset (when the order byte increments from 255 to 0). This needs to be tested thoroughly.
Bellow are all the scenarios I would like tested. For all applicable scenarios, testing should be done using both single packet, and multi-packet message.
Terms used
- Packet ID - The order byte of a packet
- Message ID - The ID of the first packet in a message
- Current ID - The ID of the packet we are expecting to see next
- OBR - Order Byte Reset: Referring to when the order byte resets from 255 to 0
Inconsistent Packet Ordering
Packets received in non-sequential order.
Test Cases
- Single packet messages received out of order
- Multi-packet messages (complete sequential messages) received out of order
- Packets within a multi-packet message received out of order
- Single packet message(s) received between the packets of a multi-packet message
- Packets from multiple multi-packet messages received intermingled
- Packets from after the OBR received before those from before
Expected Result
- In all cases, messages should be processed and in the order they were sent
- In the case of OBR, the following behavior is expected:
- If the current ID is greater than 200, and the ID of the packet received is less than 50, we assume that packet is from a future message. If this condition is not true, the packet should be dropped as an orphan
- If the prior is true, the packet should be treated as having a "higher" ID than all packets with an ID <= 255 (essentially handled as if 256 were added to the packet's ID
Dropped Packets
Test Cases
- Single packet message dropped
- Some packets from a multi-packet message dropped, specifically:
- The first packet in the message
- The last packet in the message
- The first and last packet in the message
- One or more other packets (not first or last)
- Entire multi-packet message dropped
- Multiple sequential multi-packet messages dropped (2 or more)
Expected Result
- After the timeout period, if only some or none of the packets from the next expected message have been received, that message should be dropped
- If packets from a message that has already been dropped are received, they should be discarded as orpahns
- If a message is dropped, the current ID should be set to the ID of the next message (if we know it), otherwise it should be set to the ID of the next message in the buffer. If the buffer is empty, it should be set to the message ID for the next packet received.