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

[Frank Muller]

Thank you guys. Now I get it.

All this (or a summary) should go to the doc because it isn't so clear
IMHO.

/Frank

Le dim. 8 janv. 2017 à 19:44, Ameretat Reith <ameretat.reith@REDACTED> a
écrit :

> > > 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.
>
> _______________________________________________
>
> erlang-questions mailing list
>
> erlang-questions@REDACTED
>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170108/2f0f93ab/attachment.htm>