desirable future enhancement and is supported by the header.

[32]{}\
\
&\

After the transmitting node determines message priority, the node fetches the first message. A node transmits the complete message and waits for an `ACK` before sending the next message. The receiving node queues the message’s packets in a message reception buffer. The receiving node maintains a message reception buffer for each node that is connected. Each connection’s receiving buffer can buffer only one message. When a message is complete, the receiving node transmits an `ACK`. `RouteInput` handles message reconstruction and `ACK` generation. Upon receiving the `ACK`, the transmitting node transmits the next message. The `Recv<Protocol>` function handles `ACK` reception. If the connection breaks, then the node resets the message reception buffer for that connection. A node considers a connection broken when the node does not receive any packets from that neighbor for two beacon intervals. When a node does not receive a complete message, it deletes the partial message. As a result, nodes do not forward partial messages.

Deleting partial messages may seem wasteful, but dropped messages due to a lost packet occurs infrequently ([*e*.*g*. ]{}less than 0.1% of the time in the Helsinki scenario). While `ACK`s improve 