[erlang-questions] Distributed Erlang transport over SSL

[Serge Aleynikov]

Commenting on my own question. According to this documentation:
http://erlang.org/doc/apps/erts/erl_dist_protocol.html
the PORT_PLEASE2_REQ (122) query doesn't allow the caller to specify the
protocol of interest.

Note that epmd's ALIVE2_REQ (120) request does support specification of a
protocol for the registered node (though I couldn't find any mapping of a
byte to protocol type, except for 0 being TCP), but the
erts/epmd/src/epmd_srv.c:1209
loop only does "uniqueness" check by name and doesn't perform the protocol
match.

I propose extending the EPMD specification to be able to register more than
one protocol per node, and to be able to query EPMD either by name only or
by {Name, Protocol}.  When a node is queried by name, the implementation
should default to the first registered protocol.

If there's a consensus that this functionality is acceptable, I can submit
a patch.

Serge


On Thu, Oct 24, 2013 at 9:07 AM, Serge Aleynikov <serge@REDACTED>wrote:

> I've been experimenting with starting Erlang distribution with both TLS
> and TCP distributed transports as the "-proto_dist" option allows to
> specify multiple modules handling distributed transport setup, but stumbled
> across the fact that when both inet_tls and inet_tcp is specified, it fails
> to register the second transport with EPMD.
>
> I think the answer is no, but is there a way to tell EPMD that the same
> node can have more than one port registered for a given node per protocol
> it supports?
>
> If it's not possible, maybe I would need to roll out a custom distributed
> transport handling module that would conditionally upgrade the incoming
> connection from TCP to SSL based on some user-logic (e.g. if a node doesn't
> belong to a local cluster).  Has anyone done anything similar?
>
>
> On Mon, Oct 21, 2013 at 12:39 PM, Motiejus Jakštys <desired.mta@REDACTED>wrote:
>
>> On Mon, Oct 21, 2013 at 5:56 PM, Serge Aleynikov <serge@REDACTED>
>> wrote:
>> > seem to be any documentation of if it's possible to give hints to a
>> given
>> > node to use transport alternative to the one used by current node at
>> startup
>> > when connecting to given nodes.
>> >
>> > If this is not supported, I would opt for this feature request as this
>> seems
>> > to be a very general case when running node configurations spanning
>> multiple
>> > clusters.
>>
>> Hi,
>>
>> See Patrick Nyblon's reply to a similar question:
>> http://erlang.org/pipermail/erlang-questions/2012-October/069876.html
>>
>> From the last paragraph I infer that what you are trying to do is
>> supported or easily supportable (lacks details though).
>>
>> --
>> Motiejus Jakštys
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131024/f44fdbf4/attachment.htm>