[erlang-questions] How does Erlang TCP determine the end of a TCP stream?

[Eric des Courtis]

On Tue, Oct 31, 2017 at 4:04 PM, scott ribe <scott_ribe@REDACTED>
wrote:

> On Oct 31, 2017, at 1:38 PM, Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED> wrote:
> >
> > If you can, run with something like {packet, 4}. It is simple and works.
> Delimiters are worse because you have to scan for them and you often need
> to escape them in your payload. A Length-Value-Type encoding provides
> framing in which you don't have to scan and you don't need to escape.
> Putting the type last in the packet is debatable, but one advantage is that
> other languages have to allocate a full buffer which can often eliminate
> certain security-concerning bad implementations.
>
> I like length-prefixed messages, and I like that Erlang has such direct &
> easy support built-in. I'm just going to suggest one more thing: add your
> own checksum at the end. In case there's any bug anywhere in decoding
> packets, this prevents the kind of error where you get out of sync and are
> then taking what should be message data as your 4 bytes of length.
>
I think this is probably unnecessary since an implementation for something
like {packet,4} is trivial to begin with so you will likely never see an
issue with it. Not to mention UDP and TCP both have checksums checked by
the OS anyway.

>
> Admittedly, that is far less likely with OTP's built-in implementation
> than if you're writing your buffering and decoding. But it's also possible
> for a sender to send a bogus length, or maybe the length is right but it
> fails to send the last byte before sending the length of the next message...
>
> --
> Scott Ribe
> https://www.linkedin.com/in/scottribe/
> (303) 722-0567
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171031/c89f41a0/attachment.htm>