Add extra stuff to a “standard” encoding? Sure, why not

Re:Add extra stuff to a “standard” encoding? Sure, why not by rkangel on Wednesday September 20, 2023 @10:45AM (#37584842)

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.

[ Parent | on HN ]

Re:Add extra stuff to a “standard” encoding? Sure, why not by mannyv on Wednesday September 20, 2023 @01:28PM (#37587027)

"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?

[ Parent | on HN ]

Re:Add extra stuff to a “standard” encoding? Sure, why not by rkangel on Wednesday September 20, 2023 @03:15PM (#37588689)

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.

[ Parent | on HN ]