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

asdf asdf codewiget95@REDACTED
Tue Oct 31 20:23:50 CET 2017


Is there a common solution to this problem? Erlang was built to be used in servers/switches, i would assume that there was a solution built into OTP?

If not, do you handle it just at the application later with gen_tcp:recv() and read X bytes at a time from the socket based on delimiters and such? How would you reconcile this with using a gen_server implementation that receives messages from the ssl socket in handle info ?

I appreciate the help, I’m happy I didn’t roll this further

On Oct 31, 2017, 12:21 PM -0400, Stanislaw Klekot <erlang.org@REDACTED>, wrote:
> On Tue, Oct 31, 2017 at 12:10:49PM -0400, code wiget wrote:
> > Vimal - I am using {active, once}. And I like when it comes in as
> > a full packet, so I do not want to change anything that could
> > eliminate that behavior.
> This behaviour is a coincidence that bases on your Erlang code being
> able to keep up with the sender, and as such, it's brittle.
> Do a test: wait some time (1s) in your code before setting {active,once}
> again and see what you'll get. My bet is several packets clumped
> together.
> This is how read() and recv() work on stream BSD sockets. If the
> socket's buffer is non-empty, they return whatever is in the buffer (up
> to read length). There's nothing magical that Erlang would do on the
> sockets for {packet,raw}.
> --
> Stanislaw Klekot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171031/2eb50e68/attachment.htm>

More information about the erlang-questions mailing list