[erlang-questions] Problems with sending UDP datagrams without buffering

[mats cronqvist]

Matthias Lang <matthias@REDACTED> writes:

> On Wednesday, October 29, Mark Geib wrote:
>
>> Yes, I am using UDP, not TCP. And to confirm, I am sending 700 bytes,
>> never any more. I see the 7000 byte datagram in WireShark on another
>> system monitoring the network. The 7000 bytes are reported as fragmented
>> packets that have been re-assembled. I am an sending the 700 bytes every
>> 20 miliseconds.
>
>> I am assuming that erlang is buffering in a lower layer, but could be
>> the linux network stack as well.
>
> If either of those two assumptions were true, then erlang (or linux)
> would break pretty much every UDP protocol there was. Everyone with
> a SIP stack would be screaming blue murder. They're not, so those 
> assumptions look unlikely.

  possibly relevant? from the inet:setopts doc;

{delay_send, Boolean} 
    Normally, when an Erlang process sends to a socket, the driver
    will try to immediately send the data. If that fails, the driver
    will use any means available to queue up the message to be sent
    whenever the operating system says it can handle it. Setting
    {delay_send, true} will make all messages queue up. This makes the
    messages actually sent onto the network be larger but fewer. The
    option actually affects the scheduling of send requests versus
    Erlang processes instead of changing any real property of the
    socket. Needless to say it is an implementation specific
    option. Default is false.

  mats