<div dir="ltr"><div><div>Seems a good idea but also a dangerous one.<br><br></div>I think I will stay with receiving {udp, Socket, Host, Port, Bin} messages<br></div><div>in controlling process and dispatch from there.<br><br></div><div>But now I face another problem...<br></div><div>I have :<br><br>handle_info({udp, Socket, Host, Port, Bin}, State)  -><br>    {noreply, State};<br></div><div><br><br></div><div>In a few minutes the memory allocated to binary increases to ~ 500MB<br></div><div>by running the command:<br><br>fmpeg -f lavfi -i aevalsrc="sin(40*2*PI*t)" -ar 8000 -f mulaw -f rtp rtp://<a href="http://10.10.13.104:5004">10.10.13.104:5004</a><br><br></div><div>It seems that the Bins are accumulated in the process memory area, an never are deallocated<br></div><div>unless the process is killed, which is not an option.<br><br></div><div>How can I manage this and to avoid running out of memory in a matter of minutes ?<br></div><div><br></div><div>If I change the clause to:<br>handle_info({udp1, Socket, Host, Port, Bin}, State) -><br><br></div><div>memory stays at 190KB.<br><br></div><div>So as long as the process receives the packet, this is accumulated in binary memory are<br></div><div>and never deallocated.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 2:23 PM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Dec 9, 2015 at 1:11 PM Sergej Jurečko <<a href="mailto:sergej.jurecko@gmail.com" target="_blank">sergej.jurecko@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:59 PM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span></span><div>You can if you tell to the udp socket to reuse the port:</div><div><a href="https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425" target="_blank">https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425</a><br></div><div><br></div><div>If you do this any process will be able to reuse it and send/recv to it.</div><br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This enables you to call gen_udp:open for port X from multiple processes. Unfortunately as long as first socket is alive, all traffic will go there. So it's just a reliability improvement (if first process goes down), but not a scalability improvement.<br><br></div></div></div></div></blockquote><div><br></div></span><div>Well it would allows you to open different socket for the same ports for recv. Normally the threads should compete to get the data according to </div><div><br></div><div><a href="https://lwn.net/Articles/542629/" target="_blank">https://lwn.net/Articles/542629/</a></div><div><br></div><div>So until a process is on another thread or CPU it should increase the concurrency. <br></div><div><br></div><div>- benoît</div></div></div>
</blockquote></div><br></div>