gen_udp:recv()

[Raimo Niskanen]

On Wed, Apr 07, 2021 at 02:11:59PM +0200, Jesper Louis Andersen wrote:
> On Mon, Apr 5, 2021 at 4:21 PM Avinash Dhumane <trigunatit@REDACTED> wrote:
> 
> > My need for the socket is {active, false}. I had tried with {active, true}
> > in the past, and got the datagrams as individual messages in the inbox of
> > my process. So, I assume that there will be one call to recv() per
> > datagram. I do not have the setup to test {active, false}; hence, I am not
> > sure about the behaviour of (and, rationale for) Length argument to recv().
> >
> >
> It's due to being there in low level socket handling (in C). You need to
> specify the size of the buffer to write the result into. It matters
> somewhat. While Ethernet normally specifies a limit of 1500 bytes (minus
> header, minus tagging, ...), a local loopback interface can easily be 16k,
> 64k, or more. And if you are considering a high count of receivers, it
> might be wise to limit the maximal size you are willing to receive.
> 
> As for the overhead: if you have many small messages and need to have a
> high processing rate, I'm going to suggest you either try {active, N} or go
> the route Max laid out by moving the processing loop into C to get it fast
> enough. You can work backwards: 100k messages per second means you have to
> process messages at a rate of one per 10 microseconds. At those rates, it
> isn't uncommon you need some kind of microbatching to keep up.

There is also an option {read_packets,N} that is useful to combine with
{active,N} or {active,true}.  It sets how many datagrams to read in a tight
loop before leaving the inet_drv ready for input callback.  The default is 5.
If you set it too high you can flood the VM with more datagrams than
it can manage.

/ Raimo Niskanen


> 
> 
> -- 
> J.

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB