<div dir="ltr"><div>Hi <span class=""><span style="color:rgb(34,34,34)" class="">Bengt,<br><br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">Yes I am aware that udp sockets are working different than tcp sockets,<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">but I was wondering if there is an idiom for udp as it is for tcp to make things concurrent.<br><br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">Having in mind the limitations of udp it seems that the best option <br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">is to implement the version with a controller process that receives udp packets <br>and in spawning processes to actually handle that packet based some info, and immediately<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">fetch the next message from message box.<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">My only concern here is the bottleneck. The message box can easily be overloaded <br>and the response of the server exponentially delayed.<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">Is there any best practices to handle such situations avoiding message box overloading<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">while handling say 1 million of concurrent (udp) connections ?<br><br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">Thank you,<br><br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class="">/Bogdan<br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class=""><br><br></span></span></div><div><span class=""><span style="color:rgb(34,34,34)" class=""><br></span></span></div><span class=""><span style="color:rgb(34,34,34)" class=""></span></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 12:35 PM, Bengt Johansson E <span dir="ltr"><<a href="mailto:bengt.e.johansson@ericsson.com" target="_blank">bengt.e.johansson@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="SV">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Bogdan!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">Your questions make me a bit confused. I wonder *<b>why</b>* you want two processes waiting for packets from the same socket and *<b>what</b>*
 you expect to happen?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">But! UDP lacks support for connections mainly since it is a message based protocol and hence is devoid of any connection abstraction
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d" lang="EN-US">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">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. </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d" lang="EN-US">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">Hope that helps!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">BR, BengtJ<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US"> <a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a> [mailto:<a href="mailto:erlang-questions-bounces@erlang.org" target="_blank">erlang-questions-bounces@erlang.org</a>]
<b>On Behalf Of </b>Bogdan Andu<br>
<b>Sent:</b> den 9 december 2015 10:15<br>
<b>To:</b> Erlang<br>
<b>Subject:</b> [erlang-questions] UDP concurrent server<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">following the thread <a href="https://groups.google.com/forum/?hl=en#!topic/erlang-programming/6Q3cLtJdwIU" target="_blank">
https://groups.google.com/forum/?hl=en#!topic/erlang-programming/6Q3cLtJdwIU</a><u></u><u></u></p>
</div>
<p class="MsoNormal">as it seems that POSt to topic does not work<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
After more tests the basic questions that remains ..<br>
<br>
Is there a way to have more than one process be blocked<br>
in gen_udp:recv/2 call as this seems to not be possible,<br>
probably because the way udp sockets work.<br>
<br>
Sequentially works as expected, but when when I try to spawn another process<br>
that makes and attempt to execute gen_udp:recv/2 while the first process already does<br>
gen_udp:recv/2 , the second process gives elready error. This means that 2 process<br>
cannot concurrently do gen_udp:recv/2 .<br>
<br>
In scenario with socket {active, once} or {active, true} there is only one process that can<br>
receive the message from socket (the one that does gen_udp:open/2 ),<br>
and for multi-threaded applications this quickly can become a bottleneck.<br>
In this case, however, elready error disappears of course.<br>
.<br>
I tried both variants and both have disavantages.<br>
<br>
Is there an idiom for designing a udp concurrent server in Erlang?<br>
So far, it seems impossible.<u></u><u></u></p>
</div>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>