Hacker News Reader

> So if you're ever doing this for a UART or network stream or something, always do the delimiter approach!

I'm confused. I mean for UART, sure. But network streams is usually sent over a protocol that recovers lost data. Am I reckless for sending length-prefixed data chunks over TCP?

View on HN

No, you're right that this approach is ok for TCP streams. I shouldn't have thrown that in there without clarification that I meant something more generic.

I actually use SLIP for packetisation over TCP anyway, because then syncing for any other logging or diagnostic thing that joins halfway through is easy. Basically I find it to just be a more robust system.

"I actually use SLIP for packetisation over TCP anyway"

Whoa, that's an acronym I haven't heard in a long time.

SLIP/TCP seems redundant. Your serial encoding IP then sending it over TCP/IP? Is this a tunnel?

TCP is a stream with no packet boundaries. If you want to separate that stream into a series of messages then you need to do packetisation. The SLIP delimiter approach is a pretty good one.

You're right that it was originally for segmenting a serial link to send separate IP packets (so you could theoretically have SLIP over TCP over IP over SLIP), but it works just as well in other contexts.

Reply on news.ycombinator.com