<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">A good thing about the legacy epmd is that it's slim, and it can be supervised separately from Erlang VM (e.g. systemd).  I am not so sure that the C language choice for the current epmd is bad.  The implementation is simple, and does well, unless you are running in limitations of a specific OS (such as RTEMS) that require to have an embedded epmd. Running an epmd-like replacement in Erlang in a general case could be tricky when running multiple nodes on the same host as now the epmd would be dependent on a single node's availability, and actually the whole epmd protocol might need to be revised.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Rather than replacing epmd, I would be much more interested in extending the epmd functionality to handle:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">1. Auto-discovery of running local nodes in case of epmd restarts.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">2. Support of multiple distribution transport protocols for one node (*)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I would love to see some progress on #2, as it's a very big limitation that presently a node is limited to a single distributed transport.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Serge</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(*) Previously I gave a shot at extending epmd and distribution to support SSL, TCP, Unix Domain Sockets, and other transports, but given the scope of impact that patch was rejected by the OTP team.</div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif"><a href="https://github.com/erlang/otp/pull/121">https://github.com/erlang/otp/pull/121</a></font><br></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif"><a href="http://erlang.org/pipermail/erlang-patches/2014-January/004522.html">http://erlang.org/pipermail/erlang-patches/2014-January/004522.html</a></font><br></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 6:57 PM, Geoff Cant <span dir="ltr"><<a href="mailto:nem@erlang.geek.nz" target="_blank">nem@erlang.geek.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, I find EPMD to be a regular frustration when deploying and operating Erlang systems. EPMD is a separate service that needs to be running for Erlang distribution to work properly, and usually (in systems that don’t use distribution for their main function) it's not set up right, and you only notice in production because the only time you use for distribution is to get a remote shell (over localhost). (Maybe I’m just bad at doing this, but I do it a lot)<br>
<br>
Erlang node names already encode host information — ‘descriptive_name@hostname’. If we include the erlang distribution listen port too, that would remove the need for EPMD. For example: ‘descriptive_name@hostname:distribution_port’. Node names using this scheme would skip the EPMD step, otherwise erlang distribution would fall back to the current system.<br>
<br>
<br>
My questions for the list are:<br>
* Are you annoyed by epmd too?<br>
* Do you think this idea is worth me writing up into an EEP or writing a pull request?<br>
* Do you think this idea is unworkable for some reason I’m overlooking?<br>
<br>
Thanks,<br>
-Geoff<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>