<div>Thank you guys. Now I get it.</div><div><br></div><div>All this (or a summary) should go to the doc because it isn't so clear IMHO. </div><div><br></div><div>/Frank</div><div><br><div class="gmail_quote"><div>Le dim. 8 janv. 2017 à 19:44, Ameretat Reith <<a href="mailto:ameretat.reith@gmail.com">ameretat.reith@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > 2017-01-07 14:04 GMT+03:00 Frank Muller<br class="gmail_msg"><br>> > <<a href="mailto:frank.muller.erl@gmail.com" class="gmail_msg" target="_blank">frank.muller.erl@gmail.com</a>>:<br class="gmail_msg"><br>> ><br class="gmail_msg"><br><br class="gmail_msg"><br>> > I understand the associated doc, but what i can’t get is how this<br class="gmail_msg"><br>> > option affects me if i set it for example with:<br class="gmail_msg"><br>> > 1. {read_packets, 20} + {active, once}<br class="gmail_msg"><br>> > 2. {read_packets, 20} + {active, 100}<br class="gmail_msg"><br><br class="gmail_msg"><br>1:<br class="gmail_msg"><br>Once there is data in socket, you'll get it and then your socket will<br class="gmail_msg"><br>not remain active anymore. you'll get another packet when you set socket<br class="gmail_msg"><br>as active again and there is a more data.<br class="gmail_msg"><br><br class="gmail_msg"><br>2:<br class="gmail_msg"><br>Once there is data in socket, up to twenty datagrams will be read and<br class="gmail_msg"><br>will be passed to target process. If there is more data, It'll be<br class="gmail_msg"><br>processed on next polling iteration over and over until socket is not<br class="gmail_msg"><br>active anymore.<br class="gmail_msg"><br><br class="gmail_msg"><br><br class="gmail_msg"><br>It's like this:<br class="gmail_msg"><br><br class="gmail_msg"><br>while true:<br class="gmail_msg"><br>        if socket_is_active():<br class="gmail_msg"><br><br class="gmail_msg"><br>                // this is blocking polling function, a<br class="gmail_msg"><br>                // select/poll/epoll_wait loop<br class="gmail_msg"><br>                if there_is_data_for_reading_in_socket():<br class="gmail_msg"><br><br class="gmail_msg"><br>                        N = 0<br class="gmail_msg"><br>                        while N < read_packets:<br class="gmail_msg"><br><br class="gmail_msg"><br>                                packet = non_blocking_read()<br class="gmail_msg"><br><br class="gmail_msg"><br>                                if socket_had_data(packet):<br class="gmail_msg"><br>                                        N--<br class="gmail_msg"><br><br class="gmail_msg"><br>                                        pass_to_process(packet)<br class="gmail_msg"><br><br class="gmail_msg"><br>                                        update_active_status()<br class="gmail_msg"><br>                                else:<br class="gmail_msg"><br>                                        break<br class="gmail_msg"><br><br class="gmail_msg"><br><br class="gmail_msg"><br>Basically there is a polling loop to select/poll/epoll on set of file<br class="gmail_msg"><br>descriptors. There is also a number for packets that will be read if<br class="gmail_msg"><br>polling loop notifies that socket has data, it is read_packets.<br class="gmail_msg"><br>After certain number of packets is read, socket will be passive; it<br class="gmail_msg"><br>means looping function won't poll for that socket anymore, that number<br class="gmail_msg"><br>is X in {active, X}.<br class="gmail_msg"><br><br class="gmail_msg"><br>> > How many packets my process will receive in each case?<br class="gmail_msg"><br>> ><br class="gmail_msg"><br>> > And are these packets send as multiple messages one packet at a<br class="gmail_msg"><br>> > time, or as one message representing a list of N packets?<br class="gmail_msg"><br><br class="gmail_msg"><br>One message for each datagram (packet).<br class="gmail_msg"><br><br class="gmail_msg"><br>> > Still didn't get it. In your example 100 UDP packets arrive so the<br class="gmail_msg"><br>> > socket's ready for reading. Then, N=5 are read out of 100.<br class="gmail_msg"><br>> ><br class="gmail_msg"><br>> > Why you said 5 will be read until new one arrives?<br class="gmail_msg"><br>> > There's still 95 ready for reading right away after delivering the<br class="gmail_msg"><br>> > first 5. I'm right?<br class="gmail_msg"><br><br class="gmail_msg"><br>Assuming socket's read_packet is set to 5, 5 packets will be read and<br class="gmail_msg"><br>on next polling iterations, buffered packets will be processed. There<br class="gmail_msg"><br>is no need for more packets since there already are in kernel buffer.<br class="gmail_msg"><br><br class="gmail_msg"><br>> On Sun, 08 Jan 2017 15:31:49 +0000<br class="gmail_msg"><br>> Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" class="gmail_msg" target="_blank">jesper.louis.andersen@gmail.com</a>> wrote:<br class="gmail_msg"><br><br class="gmail_msg"><br>> Packet delivery happens roughly as follows:<br class="gmail_msg"><br>> {read_packets, K} controls what happens in 3. in the above. If set at<br class="gmail_msg"><br>> 5, once the kernel tells the VM there are data available to read, the<br class="gmail_msg"><br>> VM will read out 5 packets. It won't read more packets until a new<br class="gmail_msg"><br>> packet arrives at the socket in which case it will read up to 5<br class="gmail_msg"><br>> packets more.<br class="gmail_msg"><br><br class="gmail_msg"><br>Actually It will read more packets if socket is still active and there<br class="gmail_msg"><br>is data. Documentation is a little ambiguous too:<br class="gmail_msg"><br><br class="gmail_msg"><br>> {read_packets, Integer}(UDP sockets)<br class="gmail_msg"><br>> Sets the max number of UDP packets to read without intervention from<br class="gmail_msg"><br>> the socket when data is available. When this many packets have been<br class="gmail_msg"><br>> read and delivered to the destination process, new packets are not<br class="gmail_msg"><br>> read until a new notification of available data has arrived.<br class="gmail_msg"><br><br class="gmail_msg"><br>Here, *notification of available data* does not mean expectance for<br class="gmail_msg"><br>*new* data.<br class="gmail_msg"><br><br class="gmail_msg"><br>I think read_packets is more useful to overcome blocking call overhead<br class="gmail_msg"><br>of polling functions rather than being an flood protection solution. If<br class="gmail_msg"><br>we are experiencing burst of packets, reads will be delayed a little but<br class="gmail_msg"><br>will still affect and now with more polling syscalls too.<br class="gmail_msg"><br>_______________________________________________<br class="gmail_msg"><br>erlang-questions mailing list<br class="gmail_msg"><br><a href="mailto:erlang-questions@erlang.org" class="gmail_msg" target="_blank">erlang-questions@erlang.org</a><br class="gmail_msg"><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" class="gmail_msg" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br class="gmail_msg"><br></blockquote></div></div>