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