All committers have signed the CLA.

Hello, thanks for the PR. Looks good, except lacking tests and docs as your say.

First a question though, what is the reason for epmd using a different resolving strategy than the one that inet uses?

Thanks for taking a look. I'll look into creating tests straight away.

Currently the interface of erl_epmd doesn't seem to be documented nor could I find another good place where to add this piece of information. Do you have a suggestion where to add it? I can also try and create initial documentation for erl_epmd but that is a bit more work.

My first and so far only use case would be to use multicast or broadcast to a known port. A listener will pick up all nodes in the local network and save them in some kind of registry. My epmd module will talk to this registry for resolving name to IP address. I have already implemented a version of this using Multicast DNS.
A second use case would be to have nodes registering to a central k/v store. The empd module would then ask the k/v store to turn a name into an IP. This could be useful for any service discovery and registry framework.

I'm wondering a bit, is the erl_epmd the best place to put this? It is really about finding which ip the nodehostname represents, as the IP is also used to do the distributed connect, which has nothing to do with epmd.

An idea, how about extending the inet:getaddr API to be able to do this:
inet:getaddr("test.foo.bar", inet, [{custom, Module}]).

This would allow many more services to use the callback module for resolving the IP. It could even be configured in kernel to be used for all lookups using the stratagies described here: http://erlang.org/doc/apps/erts/inet_cfg.html

We'd also have to add a way to configure inet_tcp_dist to use custom options to the inet:getaddr call.

What do you think?

@legoscia Do you have any thoughts on this?

That is a really interesting thought. I can see that this could prove useful for MDNS in general, but other solutions could be built as well of course.
From another point of view you though, I don't see why, on many occasions, you would call inet:getaddr/3 with your own resolver if you can also just call your own resolver directly with Module:Function. Even in the case of epmd it already allows you to create your own epmd module so you can call your own resolver (and fallback to normal epmd for other operations). I think this would really only be beneficial if inet:getaddr/2 is used on more places inside otp where people might want to add their own resolving method. I'm not familiar enough with otp to see if that is the case or not.

I see Erlang nodenames not as 'hostnames' per se. It is a way of naming and identifying Erlang VMs using some registry. It happens to be that DNS was the chosen registry (and rightfully so). I like to see "epmd module" as an erlang discovery module, not limited to ports. But this just reflects my personal opinion.

So, I've been thinking a bit and I see your point. Both approaches have their merits, but I think I/we are leaning towards your approach right now. I still like the idea of adding a callback module to inet:getaddr, but maybe not to solve the problem that you are trying to solve.

However I think that it would be a good idea for the "address_please" call to also allow returns of {ok, Ip, Port}, so that it would be possible to lookup both address and port in one call.

Also the dist_util:start_timer(SetupTime), should most likely be setup around the "address_please" call.

Regarding docs, it is about time that we add some. In the erts User's Guide there is a chapter called "How to Implement an Alternative Carrier for the Erlang Distribution". We should add a chapter called "How to Implement an Alternative Service Discovery for Erlang Distribution" and in there document the erl_epmd API. Linking from the various places where one would expect to find info about how to implement an alternative service discovery mechanism.

What do you think?

Sounds great! I'll see if I can come up with the necessary patches. Do you want documentation as part of this PR or separately, since it would cover more then just this feature?

Initially (in a separate dist module) I implemented address_and_port_please, see https://github.com/tverlaan/inet_tcp_dist/blob/master/lib/inet_tcp_dist.ex#L48. Would you prefer to keep address_please or use the more descriptive, despite long name?

Put the doc changes in this pr.

I don't have a strong opinion regarding the naming. Choose what you find to be the best.

How is it going? Need any help with anything?

I've been quite busy past few weeks. I'm slowly making some progress. Thanks!

Hello! Any chance of getting this done within the next week? I'd like for it to be part of the OTP-21 rc1 if possible.

Hey, sorry, have been on holiday as well. I'll finish it this week!

Hi! I finally got around on finishing the documentation. I also merged master into my branch to resolve a conflict in inet_tls_dist. There was a small change in code I moved to another function, so I moved that change as well so it is still present.

Happy to get any feedback on the documentation :)

Great! I'll have a look after the OTP-21 rc1 release is done, which quite soon.

Would you mind doing a rebase ontop of master instead of merging? We never merge master into our development branches, but instead rebase them ontop until they are merged upstream.

Ok, rebased my branch on top of master instead of merging it :-)

The xmllint fails in

../xml/alt_disco.xml:113: element p: validity error : Element taglist is not declared in p list of possible children
</p>

If you run: "make xmllint" it should reproduce the error.

I couldn't get xmllint work right now (I'll look into it), but I think I resolved the error by looking at other docs.

I just pushed xmllint checks into the travis builds on latest master, so if you rebase again you will get the checks in travis instead of having to run them yourself.

Looks great! I did some small changes and restructured the alt_disco chapter a bit. If you are happy with my changes, please squash all of your and my changes into a single commit and push them to the PR and I'll merge this change.

Thanks. It looks good! I added one sentence and squashed it all in one commit. I hope that's okay!

I did a force push with some link changes.

Merged! Thanks for you contribution!