Just to bring this back up again, I looked at ejabberd_listener.erl and as far as I can tell, the strategy is to have a "master acceptor" supervisor that babysits some processes doing gen_tcp:listen() and gen_tcp:accept(), in a "normal" blocking manner.

When each worker's gen_tcp:accept() returns with a client socket, the socket is then passed along to a separate "controller" process (supervised by something else) and the worker goes back to accepting.

<br><br>Does the fact that the worker processes are properly supervised and can be administrated through supervision make this an "officially safe" way to have a non-blocking tcp server?<br><br><div><span class="gmail_quote">

On 8/17/07, <b class="gmail_sendername">Samuel Tesla</b> <<a href="mailto:samuel.tesla@gmail.com">samuel.tesla@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I suppose the question really becomes, then, how can you write a <span id="st" name="st" class="st">TCP server using the documented APIs of Erlang/OTP that you can reasonably expect to remain the same between releases?

The APIs in prim_inet aren't intended to be used.  They can change between releases and that will cause problems with the original code you posted as well.  Whereas a solution that uses the functions exported from gen_tcp can be expected to survive upgrades to the OTP environment.

<br><br>I'm currently looking at ejabberd to see how they do things, as they manage a jabber server with only gen_tcp.<br><span class="sg"><br>-- Samuel</span><div><span class="e" id="q_114760d3aa29bb5e_2"><br><br><div>

<span class="gmail_quote">On 8/17/07, <b class="gmail_sendername">Serge Aleynikov

</b> <<a href="mailto:saleyn@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">saleyn@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Samuel,<br>

<br>Thanks for your input.  I reviewed your modifications and have to say<br>that there are several problems with this approach.<br><br>1. Not doing asynchronous accept and relying on a separate process to<br>accept connections may be *dangerous* if not handled properly as it

<br>introduces race conditions that could potentially block the server<br>permanently.<br><br>Here's an important quote from ACE book "C++ Network Programming Vol.1":<br><br>"When an acceptor socket is passed to select(), it's marked as "active"

<br>when a connection is received. Many servers use this event to indicate<br>that it's OK to call accept() without blocking. Unfortunately, there's a<br>race condition that stems from the asynchronous behavior of TCP/IP In

particular, after select() indicates an acceptor socket is active (but before accept() is called) a client can close its connection, whereupon accept() can block and potentially hang the entire application process.

<br>To avoid this problem, acceptor sockets should always be set into<br>non-blocking mode when used with select()."<br><br>This applies to your changes indirectly.  Under the hood of the network<br>driver, it still does the asynchronous accept, so the paragraph above

<br>doesn't apply at the driver level.  However, there may be a failure<br>between these two lines in the init/1:<br><br>         {ok, Ref} = create_acceptor(Listen_socket),<br>         {ok, #state{listener = Listen_socket,

<br>                     acceptor = Ref,<br>                     module   = Module}};<br><br>due to various reasons and despite the fact that it was linked, the<br>{'EXIT', Pid, Reason} message is presently not handled (trap_exit though

<br>is turned on), so the process will be locked forever.<br><br>The same can happen if the acceptor process dies anywhere in the middle<br>of the F() function:<br><br>     F = fun() -><br>                 {ok, Socket} = gen_tcp:accept(Listener),

<br>                 gen_tcp:controlling_process(Socket, Self),<br>                 gen_server:call(Self, {accept, Socket})<br>         end,<br><br>As mentioned above, this can likely be fixed by proper handling of the<br>

{'EXIT', Pid, Reason} and respawning acceptor when it happens.  This,<br>however presents another challenge - what if the system runs out of file<br>descriptors - your listener process will be in an unhappy more of

<br>constantly respawning acceptors that will die because of this line:<br><br>                 {ok, Socket} = gen_tcp:accept(Listener)<br><br>So you would need to monitor how many accept failures you got in the<br>last several seconds and do some intelligent recovery.  This would

<br>complicate code by quite a bit.<br><br>2. This new process is not OTP compliant - no supervisors know about it<br>and it doesn't process debug and system messages as per "6.2 Special<br>Processes" of Design Principles.  This means that you may have problems

when you upgrade your system dynamically. Partly these are some of the reasons I put together this tutorial to show how to avoid such problems all together.  :-) I hope you will find this feedback useful.

<br><br>Regards,<br><br>Serge<br><br><br>Samuel Tesla wrote:<br>> Serge,<br>><br>> I really got a lot from your guide on building TCP servers.  I really<br>> appreciate the work you put into it.  I think I've got an improvement that

<br>> you may want to consider putting up on the website.<br>><br>> I wanted to read documentation for prim_inet:async_accept/2 so I could<br>> figure out what that -1 was for, and couldn't find any documentation.  So, I

<br>> Googled and discovered that there is no documentation on purpose (<br>> <a href="http://www.trapexit.org/forum/viewtopic.php?p=29157" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.trapexit.org/forum/viewtopic.php?p=29157

</a>).  Basically, it's not a

<br>> guaranteed API between versions, whereas gen_tcp is.  So, I set out to see<br>> if I could use gen_tcp:accept/1 instead of prim_inet:async_accept/2, and I<br>> was successful.<br>><br>> I copied your source off the website and then made modifications.  I only

<br>> had to change the listener and the FSM modules, and I've attached the<br>> altered source files.  The gist of what I did was spawn a linked process<br>> which does the accept, and then sends a call back to the main listener

<br>> process.  The whole sequence until the control has to be synchronous until<br>> the FSM gets into WAIT_FOR_DATA or the socket will disconnect and you'll<br>> start getting posix errors.<br>><br>> There were a few other things I cleaned up or changed:

>  * You don't need to copy socket options, as accept/1 does that. >  * You don't need to call gen_tcp:close/1 in terminate/2 as the listening > socket will close when its controlling process exits.

<br>>  * I set {packet, 0} as I was testing with a raw telnet session.<br>><br>> I hope you find this helpful!<br>><br>> -- Samuel<br>><br><br><br></blockquote></div><br>

</span></div><br>_______________________________________________<br>erlang-questions mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org

</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote>

</div><br>