Re: gen_udp:recv()

Raimo Niskanen <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Message-ID <[email protected]>
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 <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.