I'm developing a high-speed distributed database using Rust and specific tech like io_uring, eBPF, and the NVMe API. Most libraries aren't usable, so I'm building everything from scratch, starting with a custom event loop. I've currently implemented Unix Domain Socket as well as UDP and TCP without TLS or SSL because I'm still learning that part. I'd like to generalize the question to cover various protocols (such as UDS, UDP, TCP, QUIC) both in datagram and stream formats.
Here's the scenario: Let's say Alice connects to the database and sends two commands in quick succession, without waiting for any response:
`SET KEY1 PAYLOAD1`
`SET KEY2 PAYLOAD2`
If the payloads are large enough to exceed a single packet, how should I handle this situation? How can I determine that two packets belong to the same command? I'm considering adding a RequestID or SessionID to each packet, but I'd need to know where a message splits, and the client could also send split messages initially. Figuring out the MTU for this seems inefficient. What strategies could I use to manage this?
3 Answers
Since UDP doesn't manage packet loss, you may want to add a prefix to your messages with the intended byte length and a checksum to verify integrity. Just ensure your checksum can detect out-of-order packets too, or things could get messy.
You should definitely include relevant indexing info in your datagram headers, like how many datagrams make up a message. A reliability layer to resend missing packets will also be essential. Think of using sequence numbers and packet indices to keep everything organized!
Handling this can be tricky since UDP doesn't guarantee delivery or order. One idea is to add a unique UUID for each message along with packet numbering in the header (like 1 of 6, 2 of 6, etc.). This way, if a packet gets lost, you can see which ones were sent and the receiver can send back an acknowledgment with the UUID. If the ACK isn’t returned in time, you could resend the packets. Reliable but a bit complex!
Thanks for the suggestion! So, you'd basically handle timeouts for that ACK, right?