UDP datagrams: delivery, loss и idempotency

Overview

UDP — message-oriented transport с минимальным механизмом. Один sendto() формирует одну UDP datagram с ports, length, checksum и payload. Если datagram доставлена и buffer recvfrom() достаточен, application наблюдает одну datagram, а не часть соседней datagram. Но UDP не гарантирует delivery, ordering или duplicate protection и не выполняет retransmission за приложение.

Поэтому «надёжный запрос поверх UDP» — уже отдельный application protocol. Ему нужны operation identity, timeout, bounded retry, deduplication/idempotency, maximum payload и наблюдаемая причина завершения. Положительный sendto() остаётся локальным evidence: local stack принял datagram, но remote process мог ничего не получить.

Components

• request_id=42 — стабильная identity logical operation, используемая при повторных attempts.
• UDP SOCKET — connectionless endpoint; sendto() задаёт destination для конкретной datagram.
• one UDP datagram — transport message с собственной length boundary.
• unreliable path — место, где возможны loss, reorder и duplicate без уведомления UDP application.
• recvfrom() buffer — получает payload одной datagram и source address; buffer size должен соответствовать protocol limit.
• dedup cache — хранит обработанные operation IDs достаточно долго относительно retry policy; запись результата и effect требуют atomic/idempotent design.
• side-effect handler — выполняет бизнес-операцию после validation и duplicate check; сам cache без транзакции не создаёт exactly-once guarantee.

Scenarios

1. Datagram доставлен. Один sendto() соответствует одной доставленной datagram, которую один recvfrom() извлекает как message unit.
2. Loss и bounded retry. Local success не предотвращает drop; timer создаёт новый attempt с тем же request_id.
3. Duplicate delivery. Повторная корректная datagram блокируется dedup layer до non-idempotent side effect.

Failure modes

• Считать sendto() end-to-end acknowledgment и не иметь timeout/retry budget.
• Делать бесконечные retries без deadline, jitter и rate limit, усиливая перегрузку.
• Генерировать новый request_id при каждом retry и тем самым обходить deduplication.
• Делать неатомарный check-then-act: concurrent duplicates или crash между effect и записью cache всё равно способны повторить operation.
• Использовать receive buffer меньше maximum protocol datagram: Winsock может сообщить WSAEMSGSIZE, а лишние данные unreliable message могут быть потеряны.
• Отправлять datagrams, зависящие от IP fragmentation, вместо выбора безопасного payload size для path.
• Хранить dedup entries меньше максимального retry horizon и повторно выполнять старый side effect.

References

• RFC 768: User Datagram Protocol
• RFC 8085: UDP Usage Guidelines
• Microsoft Learn: sendto function
• Microsoft Learn: recvfrom function
• Microsoft Learn: WSAEMSGSIZE in Winsock