[erlang-questions] UDP concurrent server

[Bogdan Andu]

I am trying to build a rtp relay server for real time media transfer
between clients.

only rtp/rtpc, not sip/sds

On Wed, Dec 9, 2015 at 3:25 PM, Bengt Johansson E <
bengt.e.johansson@REDACTED> wrote:

> Hi Bogdan!
>
>
>
> I’m sure you understand the difference between TCP and UDP, I just wanted
> to highlight it for the discussion. J
>
>
>
> Given that I don’t know your application, it is difficult to give specific
> advice. But let’s assume that your application involves sending messages
> using an application specific protocol to your server. Let’s also assume
> that each client needs to communicate with the server more than once, so we
> essentially have a connection between the clients and the server.
>
>
>
> In that case you will have a dispatcher process like you mention that
> sends packets along to the processors. This could be round-robin, random or
> based on some identifier in the packet. In fact, the concurrent TCP server
> is implemented using that pattern as well, but it hands off the
> classification of connections to the TCP/IP stack by using different ports
> for each connection.
>
>
>
> I agree that it would be kind of nifty for some applications to allow the
> UDP stack to spread incoming packets to more than one receiver, but that
> would be limited to random or round-robin distribution or some similar
> simple method since it doesn’t understand the contents of the packet.
>
>
>
> Unfortunately, the dispatcher “pattern” puts a cap on the maximum possible
> concurrency. Amdahl’s law states that the maximum possible concurrency in a
> parallel system is limited by the sequential parts of the system since they
> will be saturated and then the parallel parts will just idle. So if the
> time spent in the sequential part (the dispatcher) is 10% per packet then
> you will get a maximum 10-fold increase in speed if you go parallel. If you
> spend 1% there you will get a 100-fold increase and so on.
>
>
>
> Assuming that you application does a lot of computing for each packet (or
> waits for disk etc.) you are likely not going to run into that problem, but
> if you are implementing something that does very little to the packets
> (like a router or firewall) this might be a problem for you.
>
>
>
> Note that I reason in terms of processing time, I don’t see why you can’t
> have millions of open connections if they do not communicate too much.
> Erlang is an excellent language for that kind of applications.
>
>
>
> As for over-load situations, the UDP stack will handle that for you by
> dropping packets when it’s buffers run full. If that is a problem your
> application protocol will have to handle packet retransmits by itself.
>
>
>
> Good luck with your project!
>
>
>
> BR, BengtJ
>
>
>
>
>
> *From:* Bogdan Andu [mailto:bog495@REDACTED]
> *Sent:* den 9 december 2015 12:00
> *To:* Bengt Johansson E
> *Cc:* Erlang
> *Subject:* Re: [erlang-questions] UDP concurrent server
>
>
>
> Hi Bengt,
>
> Yes I am aware that udp sockets are working different than tcp sockets,
>
> but I was wondering if there is an idiom for udp as it is for tcp to make
> things concurrent.
>
> Having in mind the limitations of udp it seems that the best option
>
> is to implement the version with a controller process that receives udp
> packets
> and in spawning processes to actually handle that packet based some info,
> and immediately
>
> fetch the next message from message box.
>
> My only concern here is the bottleneck. The message box can easily be
> overloaded
> and the response of the server exponentially delayed.
>
> Is there any best practices to handle such situations avoiding message box
> overloading
>
> while handling say 1 million of concurrent (udp) connections ?
>
> Thank you,
>
> /Bogdan
>
>
>
>
>
>
>
> On Wed, Dec 9, 2015 at 12:35 PM, Bengt Johansson E <
> bengt.e.johansson@REDACTED> wrote:
>
> Hi Bogdan!
>
>
>
> Your questions make me a bit confused. I wonder **why** you want two
> processes waiting for packets from the same socket and **what** you
> expect to happen?
>
>
>
> Generally one usually only speaks about concurrent servers regarding TCP
> where you bind to a socket waiting for incoming connections and once a
> connection is established, you spawn a process (or thread depending on
> language) and process the data coming over the connection concurrently.
>
> Note that the main loop of the server that waits for responses is always
> sequential. The new process handling the connection gets a new socket with
> a free port used only for that particular connection.
>
>
>
> But! UDP lacks support for connections mainly since it is a message based
> protocol and hence is devoid of any connection abstraction J
>
>
>
> Still the question remains what is a concurrent UDP server? I guess what
> you want to achieve is some kind of distribution of incoming packets to
> several processes to handle them. In that case you should either go for the
> solution of TCP to set up new socket for each communication or write a
> simple process that classifies the incoming packets and distributes them to
> the correct process based on some information in the packet, fi. Some
> identifier you have chosen to identify the connection. Basically  you have
> to implement an application specific load balancer – or rather load
> distributor – hoping that the time taken to actually process the packets
> greatly overshadows the time it takes to distribute them. J
>
>
>
> Anyway, there is no way the underlying UDP stack and/or erts can make the
> decision for you. To which process to send the packet that is.
>
>
>
> Hope that helps!
>
> BR, BengtJ
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* erlang-questions-bounces@REDACTED [mailto:
> erlang-questions-bounces@REDACTED] *On Behalf Of *Bogdan Andu
> *Sent:* den 9 december 2015 10:15
> *To:* Erlang
> *Subject:* [erlang-questions] UDP concurrent server
>
>
>
> following the thread
> https://groups.google.com/forum/?hl=en#!topic/erlang-programming/6Q3cLtJdwIU
>
> as it seems that POSt to topic does not work
>
>
> After more tests the basic questions that remains ..
>
> Is there a way to have more than one process be blocked
> in gen_udp:recv/2 call as this seems to not be possible,
> probably because the way udp sockets work.
>
> Sequentially works as expected, but when when I try to spawn another
> process
> that makes and attempt to execute gen_udp:recv/2 while the first process
> already does
> gen_udp:recv/2 , the second process gives elready error. This means that 2
> process
> cannot concurrently do gen_udp:recv/2 .
>
> In scenario with socket {active, once} or {active, true} there is only one
> process that can
> receive the message from socket (the one that does gen_udp:open/2 ),
> and for multi-threaded applications this quickly can become a bottleneck.
> In this case, however, elready error disappears of course.
> .
> I tried both variants and both have disavantages.
>
> Is there an idiom for designing a udp concurrent server in Erlang?
> So far, it seems impossible.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151209/6582f862/attachment.htm>