Tcp {active, true} problem

Lars Bjornfot bjornfot@REDACTED
Tue Aug 8 16:04:01 CEST 2000

Kent Boortz wrote:
> >> problem with gen_tcp. I am using {active, true} and receiving with
> >>
> >> receive
> >>         {tcp, Socket, Packet} ->
> >> end
> >>
> >> If I send packets to this at a 500 milliseconds apart I receive all of the
> >> packets perfectly and the proxy works well. My problem arises when I send
> >> a number of packets quickly( < 500 ms). I receive them as one large ascii
> >> string. I was wondering, befor I write a parser of sorts, if there is some
> >> other way to deal with this problem.
> >
> > As you already seen you can use {packet,1 | 2 | 4} to let the erlang driver
> > packetize the data for you.
> > I think the option {nodelay, true} might be of interest in this case.
> > TCP_NODELAY option is used to set aside the buffering algorithm in the os
> > kernel tcp/ip driver, leading to that the data is sent as quickly as possible
> > and not optimized as stream data.
> Are you sure that the TCP_NODELAY has that exact meaning, i.e. that it
> sets aside *all* buffering? I think the OS may choose to combine the
> data from two write operations even with that flag set. The opposite
> problem may also happen if the machine has some load, one larger
> "packet" sent may show up as two separate messages in Erlang.  It may
> work to ignore this in 99.9% of the cases but a small OS upgrade or
> some load on the machine or network may easily break the code.

TCP_NODELAY disables the Nagle algorithm. Nagle means the sender
buffers data to send full frames, or at least waits until all
outstanding frames are acknowledged before sending non-full frames.

Disabling Nagle will probably give more network traffic. Reduced
throughput and reduced latency. This may be what you want. 

But don't use it to impose some packet scheme. TCP is a stream. It is
never safe to trust that a "packet" is sent in one piece and received
in one piece, regardless of TCP_NODELAY.

More on Nagle:


More information about the erlang-questions mailing list