Close without a receipt
05close_notify is a TLS alert announcing closure. It is not an application receipt saying that an event was analyzed or saved. On a broken connection the sender can be uncertain which events arrived.
Separate failure: a connection breaks after sending an event. The sender cannot always know whether it reached the receiving syslog application. Do not invent an application receipt or exactly-once guarantee.
Source for this drawing: RFC 5425 · Read RFC section 4.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Close the transport correctly, but preserve the uncertainty of application delivery.
- A sender MUST close when it expects no later messages and MUST send close_notify before closing. It MAY close without waiting for the receiver’s close_notify (§4.4), creating an incomplete close at the receiver.
- After receiving the sender’s close_notify, the receiver MUST reply with close_notify unless it knows the sender has already closed the connection (§4.4). The normal exchange picture shows this conditional response; it does not make waiting mandatory for the sender.
- An idle receiver MAY close after an application-defined long interval; there is no fixed RFC timeout. It MUST attempt an exchange of close_notify alerts before closing. If unprepared to receive more data, it MAY close after sending its alert, creating an incomplete close at the sender (§4.4).
- The mapping has no application-layer acknowledgment (§6.3). TCP retransmission protects against some losses, but a broken TCP connection or TLS session can leave the sender unable to know which messages reached the receiving syslog application. A clean TLS close is also not a durable-storage acknowledgment.
- Retry or deduplication policy is not supplied by this mapping. Never draw an acknowledgment from a database or label every retried event exactly once merely because the transport is encrypted.
Alert arrows are schematic; no physical timing or fixed idle timeout is asserted.
Read the RFC section ↗