RFC 6587 / START HERE
Legacy syslog over TCP, before the details
Syslog over TCP: historical log transport
Syslog is a logging protocol name, not an acronym expanded here. It carries event messages toward a log collector. TCP means Transmission Control Protocol; it delivers a byte stream. This Historic RFC describes how legacy systems marked message boundaries in that stream.
The idea in one picture
A sender has a log message
Framing marks its byte boundary
A receiver recovers the message
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Existing logging systems can disagree about lengths, newlines and TCP reads. Understanding both observed framing methods helps diagnose that behavior. For new deployments the RFC recommends the separate TLS transport in RFC 5425, rather than plain TCP.
A familiar example
A fictional device sends two log events to a collector. The collector uses byte counts to recover both messages even when one TCP read stops halfway through a frame. Successful framing does not prove that the events were stored or authenticated.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Separate syslog roles from the TCP sessionSyslog carries event messages from an originator toward a collector, sometimes through a relay. On each transport hop, a sender connects to a receiver. Transmission Control Protocol (TCP) supplies an ordered byte stream. This Historic RFC records deployed plain-TCP behavior; it does not recommend plain TCP for new secure logging systems.→
- Build a frame by counting message octetsAn octet is an eight-bit byte. In octet-counting framing, a decimal message length and one space come before the complete syslog message. That count gives the receiver the message boundary without searching its contents for a special ending character.→
- Recover frames across arbitrary TCP readsTCP does not preserve an application’s send calls as matching receive calls. One read may stop inside a length prefix or message; another may contain several frames. The receiver buffers bytes and uses each frame’s declared length to decide when a complete message is available.→
- See why delimiter framing is not transparentThe older method places a trailer after the message, commonly a line feed (LF). The receiver searches for that trailer. If the same byte occurs inside the message without escaping, the receiver cannot reliably distinguish message content from the end marker.→
- Keep encoding, delivery and security limits visibleCorrect framing locates messages in bytes. It does not determine their character encoding, promise durable storage or secure the transport. This Historic description helps explain existing deployments while pointing new systems toward the separately specified TLS transport.→
This introduction explains RFC 6587 (2012). Read the original RFC ↗