[erlang-questions] UDP concurrent server

[Bogdan Andu]

Seems a good idea but also a dangerous one.

I think I will stay with receiving {udp, Socket, Host, Port, Bin} messages
in controlling process and dispatch from there.

But now I face another problem...
I have :

handle_info({udp, Socket, Host, Port, Bin}, State)  ->
    {noreply, State};


In a few minutes the memory allocated to binary increases to ~ 500MB
by running the command:

fmpeg -f lavfi -i aevalsrc="sin(40*2*PI*t)" -ar 8000 -f mulaw -f rtp rtp://
10.10.13.104:5004

It seems that the Bins are accumulated in the process memory area, an never
are deallocated
unless the process is killed, which is not an option.

How can I manage this and to avoid running out of memory in a matter of
minutes ?

If I change the clause to:
handle_info({udp1, Socket, Host, Port, Bin}, State) ->

memory stays at 190KB.

So as long as the process receives the packet, this is accumulated in
binary memory are
and never deallocated.

On Wed, Dec 9, 2015 at 2:23 PM, Benoit Chesneau <bchesneau@REDACTED> wrote:

>
> On Wed, Dec 9, 2015 at 1:11 PM Sergej Jurečko <sergej.jurecko@REDACTED>
> wrote:
>
>> On Wed, Dec 9, 2015 at 12:59 PM, Benoit Chesneau <bchesneau@REDACTED>
>> wrote:
>>
>>>
>>> You can if you tell to the udp socket to reuse the port:
>>> https://github.com/refuge/rbeacon/blob/master/src/rbeacon.erl#L414-L425
>>>
>>> If you do this any process will be able to reuse it and send/recv to it.
>>>
>>>
>> 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.
>>
>>
> 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
>
> https://lwn.net/Articles/542629/
>
> So until a process is on another thread or CPU it should increase the
> concurrency.
>
> - benoît
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151209/619f581c/attachment.htm>