<div>Hmm. I thought that something like "kill -9" wouldn't inform us that the socket has been closed until we try to do something with it. But checked – and yes, you are right, keep-alive is even bad in that case, since without it we immediately get a {tcp_closed, Socket} message.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 11:15 PM, Per Hedeland <span dir="ltr"><<a href="mailto:per@hedeland.org" target="_blank">per@hedeland.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Dmitry Demeshchuk <<a href="mailto:demeshchuk@gmail.com">demeshchuk@gmail.com</a>> wrote:<br>
><br>
>1. When we send ALIVE2_REQ and reply with ALIVE2_RESP, we establish a TCP<br>
>connection. Closing of which is a signal of node disconnection. This<br>
>approach does have a point, since we can use keep-alive and periodically<br>
>check that the node is still here on the TCP level.<br>
<br>
</div>No, the point is rather the opposite - since this is always a local<br>
loopback connection, epmd is guaranteed (by the OS/kernel) to<br>
"immediately" find out that the erlang node died (or disconnected), by<br>
means of socket close (EOF) - no matter how the death came about. TCP<br>
keep-alives, that by necessity incur a delay (and the default is<br>
typically huge) before detection of a problem, are not only inferior but<br>
pointless in this scenario.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Per Hedeland<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Best regards,<br>Dmitry Demeshchuk<br>
</div>