[erlang-questions] inets {read_packets,N} option

[Ameretat Reith]

> > 2017-01-07 14:04 GMT+03:00 Frank Muller
> > <frank.muller.erl@REDACTED>:
> >

> > I understand the associated doc, but what i can’t get is how this
> > option affects me if i set it for example with:
> > 1. {read_packets, 20} + {active, once}
> > 2. {read_packets, 20} + {active, 100}

1:
Once there is data in socket, you'll get it and then your socket will
not remain active anymore. you'll get another packet when you set socket
as active again and there is a more data.

2:
Once there is data in socket, up to twenty datagrams will be read and
will be passed to target process. If there is more data, It'll be
processed on next polling iteration over and over until socket is not
active anymore.


It's like this:

while true:
	if socket_is_active():

		// this is blocking polling function, a
		// select/poll/epoll_wait loop
		if there_is_data_for_reading_in_socket():

			N = 0
			while N < read_packets:

				packet = non_blocking_read()

				if socket_had_data(packet):
					N--

					pass_to_process(packet)

					update_active_status()
				else:
					break


Basically there is a polling loop to select/poll/epoll on set of file
descriptors. There is also a number for packets that will be read if
polling loop notifies that socket has data, it is read_packets.
After certain number of packets is read, socket will be passive; it
means looping function won't poll for that socket anymore, that number
is X in {active, X}.

> > How many packets my process will receive in each case?
> >
> > And are these packets send as multiple messages one packet at a
> > time, or as one message representing a list of N packets?

One message for each datagram (packet).

> > Still didn't get it. In your example 100 UDP packets arrive so the
> > socket's ready for reading. Then, N=5 are read out of 100.
> >
> > Why you said 5 will be read until new one arrives?
> > There's still 95 ready for reading right away after delivering the
> > first 5. I'm right?

Assuming socket's read_packet is set to 5, 5 packets will be read and
on next polling iterations, buffered packets will be processed. There
is no need for more packets since there already are in kernel buffer.

> On Sun, 08 Jan 2017 15:31:49 +0000
> Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:

> Packet delivery happens roughly as follows:
> {read_packets, K} controls what happens in 3. in the above. If set at
> 5, once the kernel tells the VM there are data available to read, the
> VM will read out 5 packets. It won't read more packets until a new
> packet arrives at the socket in which case it will read up to 5
> packets more.

Actually It will read more packets if socket is still active and there
is data. Documentation is a little ambiguous too:

> {read_packets, Integer}(UDP sockets)
> Sets the max number of UDP packets to read without intervention from
> the socket when data is available. When this many packets have been
> read and delivered to the destination process, new packets are not
> read until a new notification of available data has arrived.

Here, *notification of available data* does not mean expectance for
*new* data. 

I think read_packets is more useful to overcome blocking call overhead
of polling functions rather than being an flood protection solution. If
we are experiencing burst of packets, reads will be delayed a little but
will still affect and now with more polling syscalls too.