Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Serge Aleynikov-4
I'd like to inquire the status of the following pull request:
https://github.com/erlang/otp/pull/121

Has it been reviewed?

Thanks!

Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140103/ca1d94f8/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Henrik Nord-3
This is waiting for a technical board ruling.

so still no news I'm afraid

On 2014-01-03 16:30, Serge Aleynikov wrote:

> I'd like to inquire the status of the following pull request:
> https://github.com/erlang/otp/pull/121
>
> Has it been reviewed?
>
> Thanks!
>
> Serge
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches
> http://erlang.org/mailman/listinfo/erlang-patches

--
/Henrik Nord Erlang/OTP

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140107/872762e6/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Kenneth Lundin-4
In reply to this post by Serge Aleynikov-4
On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov <serge> wrote:

> I'd like to inquire the status of the following pull request:
> https://github.com/erlang/otp/pull/121
>
> Has it been reviewed?
>
> Thanks!
>
> Serge
>
> Hi Serge,

We have discussed your contribution at the OTP technical board and here are
the results:

Inclusion in OTP
-----------------------

Your patch touches many source files which are central for the Erlang
distribution and we feel it would require quite a lot of work from our side
as well to assure that nothing in the current distribution gets broken or
incompatible. It would also require quite deep involvement from us giving
more detailed feedback regarding interfaces, semantics etc. We can not
prioritize this at the moment so we will not include your contribution now
(which means REJECT for now).

But we really want to add this kind of functionality and want to encourage
you (and others) to continue the good work in this area for possible
inclusion in OTP at a later stage. See more info and thoughts below.


General thoughts
-----------------------

Enhancing/extending the Erlang distribution to support heterogenous
communication protocols is something we have discussed many times and it is
something that we really would like to have.

1) We would like a plugin architecture where different transport protocols
can be easily plugged in without having to change the basic Erlang
distribution or the VM.

2) It should be possible to run different protocols towards different nodes

3) should be possible to have different timeouts (NET_TICK_TIME) per
connection

4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ...

5) it should be possible to look up nodes in different ways and maybe not
only via contacting epmd on the host name which is part of the node name.
I.e having the hostname as part of the node name is not always what you
want, depending on protocol to use.

....

Your specific contribution
-----------------------------------
In your pull request you have implemented fully or partly 1,2, 4, and we
see it as a good start.

A general comment is that the diffs are showing differences on many places
in the code where you actually haven't changed anything except tabs, line
breaks and spaces. This makes it more difficult to sort out what you have
changed and added. We would like a clean diff without unnecessary touches
lines which has no relevance for the new function. If a formatting change
is needed or suggested it should be a separate commit/pull request.

Regarding details in your code we have not had the time to take a deeper
look but from a quick glance it looks good. The questionmarks are more
about how to introduce this new functionality in a safe way and what more
is needed that you have not addressed so far.


Suggested way forward
------------------------------

I think that one approach that would make it easier to include this kind of
functionality soon would be to make minimal changes to the existing
distribution code and only add or change so that it is possible to support
heterogenous protocols with code that initially can live as a separate
extension that don't need to be part of the OTP distro.
In this way the functionality can be further developed and used together
with an ordinary OTP distro (unpatched) and can easily be included later
(hopefully within a year).

Maybe you think that you already have done those minimal changes, but I
suggest you take another look and see if it is possible to find a way to
make minimal or now changes to net_kernel and epmd etc. which we could
include and then have the rest as a separate "application"/extension
project at github that can be included later.

Just some thoughts:
Maybe let the old distribution work as before and let the user choose
"new_distro" in some way and will only then get to run the new code which
allows heterogenous protocols another new EPMD or an EPMD written in Erlang
or allow for plugins of different EPMD implementations that can run in
parallell. The communication towards EPMD maybe needs to be secure as well
and then it might be much easier to implement in Erlang.

I (we) are more than willing to discuss more about how to find this minimal
patch which we think we can "safely" include and which makes it possible to
develop and use the rest as pure extensions to OTP in a first step.

Regards Kenneth, Erlang/OTP Ericsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140109/c1717fbc/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Serge Aleynikov-4
Kenneth,

Thank you for the thorough response! Your reasoning is appealing and I'd
like to engage in the discussion on how we can move on to include this
functionality in the distribution, as I believe the community will benefit
greatly from being able to run an Erlang node listening on multiple transports
concurrently.

The changes in the patch (https://github.com/erlang/otp/pull/121) cover the
following areas:

1. Extension of the EPMD distributed protocol (here we can safely add new
set of commands while being fully backward compatible)
    erts/doc/src/erl_dist_protocol.xml

2. Modification of the EPMD daemon to support the new protocol version and
to keep track of the multiple protocols/ports per node (this is also done
in a backward compatible way. Nodes supporting new protocol version
communicate using new spec, and old nodes communicate using old spec)
    erts/epmd/src/epmd.h
    erts/epmd/src/epmd.c

3. Modification of the EPMD command-line tool to talk to the local EPMD
daemon using the new protocol version (the command-line tool uses new
protocol version. This is reasonable, since it's installed together with
the version of VM supporting the new EPMD protocol features)
    erts/epmd/src/epmd_cli.c
    erts/epmd/src/epmd_cli.c
    erts/epmd/src/epmd_int.h
    erts/epmd/src/epmd_srv.c

4. Updates of the UDS distribution example code. I believe the example in
the current release is outdated (I was unable to compile it), but I patched
it anyway to illustrate the usage of the new protocol)
    lib/kernel/examples/uds_dist/src/dist_selector.erl
    lib/kernel/examples/uds_dist/src/uds_dist.erl
    lib/kernel/examples/uds_dist/src/uds_server.erl

5. Change of the net_kernel transport pluggable architecture to allow
support of the new EPMD protocol.
5.1 Net_kernel support for the new protocol.
5.2 TCPv4 support of the new protocol
5.3 TCPv6 support of the new protocol
5.4 TLS support of the new protocol
    lib/kernel/src/net_kernel.erl
    lib/kernel/src/dist_util.erl
    lib/kernel/src/inet6_tcp_dist.erl
    lib/kernel/src/inet_tcp_dist.erl
    lib/kernel/src/net_kernel.erl
    lib/ssl/src/inet_tls_dist.erl
    lib/ssl/src/ssl_tls_dist_proxy.erl
    lib/kernel/doc/src/net_kernel.xml

It seems to me that we could roll it out in two phases:

1. Implement 1,2,3 in the first phase.  This would allow to deploy a
version with EPMD supporting old and new protocols.
2. Implement changes to net_kernel and transports (4,5) to be able to talk
to new EPMDs

If agreed, I can break up my patch in two, corresponding to this plan.

What do you think?

Serge



On Thu, Jan 9, 2014 at 10:53 AM, Kenneth Lundin <kenneth.lundin>wrote:

> On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov <serge>wrote:
>
>> I'd like to inquire the status of the following pull request:
>> https://github.com/erlang/otp/pull/121
>>
>> Has it been reviewed?
>>
>> Thanks!
>>
>> Serge
>>
>> Hi Serge,
>
> We have discussed your contribution at the OTP technical board and here
> are the results:
>
> Inclusion in OTP
> -----------------------
>
> Your patch touches many source files which are central for the Erlang
> distribution and we feel it would require quite a lot of work from our side
> as well to assure that nothing in the current distribution gets broken or
> incompatible. It would also require quite deep involvement from us giving
> more detailed feedback regarding interfaces, semantics etc. We can not
> prioritize this at the moment so we will not include your contribution now
> (which means REJECT for now).
>
> But we really want to add this kind of functionality and want to encourage
> you (and others) to continue the good work in this area for possible
> inclusion in OTP at a later stage. See more info and thoughts below.
>
>
> General thoughts
> -----------------------
>
> Enhancing/extending the Erlang distribution to support heterogenous
> communication protocols is something we have discussed many times and it is
> something that we really would like to have.
>
> 1) We would like a plugin architecture where different transport protocols
> can be easily plugged in without having to change the basic Erlang
> distribution or the VM.
>
> 2) It should be possible to run different protocols towards different nodes
>
> 3) should be possible to have different timeouts (NET_TICK_TIME) per
> connection
>
> 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ...
>
> 5) it should be possible to look up nodes in different ways and maybe not
> only via contacting epmd on the host name which is part of the node name.
> I.e having the hostname as part of the node name is not always what you
> want, depending on protocol to use.
>
> ....
>
> Your specific contribution
> -----------------------------------
> In your pull request you have implemented fully or partly 1,2, 4, and we
> see it as a good start.
>
> A general comment is that the diffs are showing differences on many places
> in the code where you actually haven't changed anything except tabs, line
> breaks and spaces. This makes it more difficult to sort out what you have
> changed and added. We would like a clean diff without unnecessary touches
> lines which has no relevance for the new function. If a formatting change
> is needed or suggested it should be a separate commit/pull request.
>
> Regarding details in your code we have not had the time to take a deeper
> look but from a quick glance it looks good. The questionmarks are more
> about how to introduce this new functionality in a safe way and what more
> is needed that you have not addressed so far.
>
>
> Suggested way forward
> ------------------------------
>
> I think that one approach that would make it easier to include this kind
> of functionality soon would be to make minimal changes to the existing
> distribution code and only add or change so that it is possible to support
> heterogenous protocols with code that initially can live as a separate
> extension that don't need to be part of the OTP distro.
> In this way the functionality can be further developed and used together
> with an ordinary OTP distro (unpatched) and can easily be included later
> (hopefully within a year).
>
> Maybe you think that you already have done those minimal changes, but I
> suggest you take another look and see if it is possible to find a way to
> make minimal or now changes to net_kernel and epmd etc. which we could
> include and then have the rest as a separate "application"/extension
> project at github that can be included later.
>
> Just some thoughts:
> Maybe let the old distribution work as before and let the user choose
> "new_distro" in some way and will only then get to run the new code which
> allows heterogenous protocols another new EPMD or an EPMD written in Erlang
> or allow for plugins of different EPMD implementations that can run in
> parallell. The communication towards EPMD maybe needs to be secure as well
> and then it might be much easier to implement in Erlang.
>
> I (we) are more than willing to discuss more about how to find this
> minimal patch which we think we can "safely" include and which makes it
> possible to develop and use the rest as pure extensions to OTP in a first
> step.
>
> Regards Kenneth, Erlang/OTP Ericsson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140109/1894bd3c/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Geoff Cant
In reply to this post by Kenneth Lundin-4
On 2014-01-09, at 07:53 , Kenneth Lundin <kenneth.lundin> wrote:

> ...
>
>
> General thoughts
> -----------------------
>
> Enhancing/extending the Erlang distribution to support heterogenous communication protocols is something we have discussed many times and it is something that we really would like to have.
>
> 1) We would like a plugin architecture where different transport protocols can be easily plugged in without having to change the basic Erlang distribution or the VM.
>
> 2) It should be possible to run different protocols towards different nodes
>
> 3) should be possible to have different timeouts (NET_TICK_TIME) per connection
>
> 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ...
>
> 5) it should be possible to look up nodes in different ways and maybe not only via contacting epmd on the host name which is part of the node name. I.e having the hostname as part of the node name is not always what you want, depending on protocol to use.
>
> ....
>

I would like to add one general thought / principle to guide improvements to ERTS's distribution machinery:

'It should be possible to implement distribution protocols in Erlang'

(The current setup requires us to implement complicated network protocols in C, which I find just about unbearable when Erlang is close at hand)

Cheers,
--
Geoff Cant





Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Serge Aleynikov-4
Having implemented full Erlang distributed transport natively in C++ and
C#, I wouldn't say it's unbearable.  However, in some special cases, it
would indeed be interesting to bridge nodes implemented in dynamic
languages (e.g. Javascript) via some protocol that could be more simple
than the built-in distributed transport.

Frankly I would be more interested in optimizing some parts of the existing
transport, e.g. introducing special encoding 1-byte tags for boolean values
(as opposed to encoding a boolean as an atom on the wire taking 6 to 7
bytes), and other similar optimizations.

Another thing - after coding in Erlang for some time, one feels Erlang's
choice of representing strings as integer lists is natural.  However, when
bringing different languages over distributed transport, you'd want a
message {weights, [65, 66]} to be sent as a tuple with a second element
being received on the other side as a list, but the distribution encodes it
as {weights, "AB"}, and decoding it in a language that understands strings
differently than lists becomes a bit more challenging than necessary...
 Personally, I think if Erlang supported string types as a special flavor
of binaries it would be easier for it to live in heterogeneous clustered
environments...

Serge

On Thu, Jan 9, 2014 at 5:10 PM, Geoff Cant <nem> wrote:

> I would like to add one general thought / principle to guide improvements
> to ERTS's distribution machinery:
>
> 'It should be possible to implement distribution protocols in Erlang'
>
> (The current setup requires us to implement complicated network protocols
> in C, which I find just about unbearable when Erlang is close at hand)
>
> Cheers,
> --
> Geoff Cant
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140109/ea0f5c9b/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

Kenneth Lundin-4
In reply to this post by Serge Aleynikov-4
Hi Serge,

See embedded comments at the end.


On Thu, Jan 9, 2014 at 9:26 PM, Serge Aleynikov <serge> wrote:

> Kenneth,
>
> Thank you for the thorough response! Your reasoning is appealing and I'd
> like to engage in the discussion on how we can move on to include this
> functionality in the distribution, as I believe the community will benefit
> greatly from being able to run an Erlang node listening on multiple transports
> concurrently.
>
> The changes in the patch (https://github.com/erlang/otp/pull/121) cover
> the following areas:
>
> 1. Extension of the EPMD distributed protocol (here we can safely add new
> set of commands while being fully backward compatible)
>     erts/doc/src/erl_dist_protocol.xml
>
> 2. Modification of the EPMD daemon to support the new protocol version and
> to keep track of the multiple protocols/ports per node (this is also done
> in a backward compatible way. Nodes supporting new protocol version
> communicate using new spec, and old nodes communicate using old spec)
>     erts/epmd/src/epmd.h
>     erts/epmd/src/epmd.c
>
> 3. Modification of the EPMD command-line tool to talk to the local EPMD
> daemon using the new protocol version (the command-line tool uses new
> protocol version. This is reasonable, since it's installed together with
> the version of VM supporting the new EPMD protocol features)
>     erts/epmd/src/epmd_cli.c
>     erts/epmd/src/epmd_cli.c
>     erts/epmd/src/epmd_int.h
>     erts/epmd/src/epmd_srv.c
>
> 4. Updates of the UDS distribution example code. I believe the example in
> the current release is outdated (I was unable to compile it), but I
> patched it anyway to illustrate the usage of the new protocol)
>     lib/kernel/examples/uds_dist/src/dist_selector.erl
>     lib/kernel/examples/uds_dist/src/uds_dist.erl
>     lib/kernel/examples/uds_dist/src/uds_server.erl
>
> 5. Change of the net_kernel transport pluggable architecture to allow
> support of the new EPMD protocol.
> 5.1 Net_kernel support for the new protocol.
> 5.2 TCPv4 support of the new protocol
> 5.3 TCPv6 support of the new protocol
> 5.4 TLS support of the new protocol
>     lib/kernel/src/net_kernel.erl
>     lib/kernel/src/dist_util.erl
>     lib/kernel/src/inet6_tcp_dist.erl
>     lib/kernel/src/inet_tcp_dist.erl
>     lib/kernel/src/net_kernel.erl
>     lib/ssl/src/inet_tls_dist.erl
>     lib/ssl/src/ssl_tls_dist_proxy.erl
>     lib/kernel/doc/src/net_kernel.xml
>
> It seems to me that we could roll it out in two phases:
>
> 1. Implement 1,2,3 in the first phase.  This would allow to deploy a
> version with EPMD supporting old and new protocols.
> 2. Implement changes to net_kernel and transports (4,5) to be able to talk
> to new EPMDs
>
> If agreed, I can break up my patch in two, corresponding to this plan.
>
> What do you think?
>

I think it is a good idea to roll out this in 2 or more phases but I think
we need think a bit more about this before we can give a more feedback on
exactly what to include in the different phases.

Will be back with more comments/suggestions soon.

Regards Kenneth

>
> Serge
>
>
>
> On Thu, Jan 9, 2014 at 10:53 AM, Kenneth Lundin <kenneth.lundin>wrote:
>
>> On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov <serge>wrote:
>>
>>> I'd like to inquire the status of the following pull request:
>>> https://github.com/erlang/otp/pull/121
>>>
>>> Has it been reviewed?
>>>
>>> Thanks!
>>>
>>> Serge
>>>
>>> Hi Serge,
>>
>> We have discussed your contribution at the OTP technical board and here
>> are the results:
>>
>> Inclusion in OTP
>> -----------------------
>>
>> Your patch touches many source files which are central for the Erlang
>> distribution and we feel it would require quite a lot of work from our side
>> as well to assure that nothing in the current distribution gets broken or
>> incompatible. It would also require quite deep involvement from us giving
>> more detailed feedback regarding interfaces, semantics etc. We can not
>> prioritize this at the moment so we will not include your contribution now
>> (which means REJECT for now).
>>
>> But we really want to add this kind of functionality and want to
>> encourage you (and others) to continue the good work in this area for
>> possible inclusion in OTP at a later stage. See more info and thoughts
>> below.
>>
>>
>> General thoughts
>> -----------------------
>>
>> Enhancing/extending the Erlang distribution to support heterogenous
>> communication protocols is something we have discussed many times and it is
>> something that we really would like to have.
>>
>> 1) We would like a plugin architecture where different transport
>> protocols can be easily plugged in without having to change the basic
>> Erlang distribution or the VM.
>>
>> 2) It should be possible to run different protocols towards different
>> nodes
>>
>> 3) should be possible to have different timeouts (NET_TICK_TIME) per
>> connection
>>
>> 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ...
>>
>> 5) it should be possible to look up nodes in different ways and maybe not
>> only via contacting epmd on the host name which is part of the node name.
>> I.e having the hostname as part of the node name is not always what you
>> want, depending on protocol to use.
>>
>> ....
>>
>> Your specific contribution
>> -----------------------------------
>> In your pull request you have implemented fully or partly 1,2, 4, and we
>> see it as a good start.
>>
>> A general comment is that the diffs are showing differences on many
>> places in the code where you actually haven't changed anything except tabs,
>> line breaks and spaces. This makes it more difficult to sort out what you
>> have changed and added. We would like a clean diff without unnecessary
>> touches lines which has no relevance for the new function. If a formatting
>> change is needed or suggested it should be a separate commit/pull request.
>>
>> Regarding details in your code we have not had the time to take a deeper
>> look but from a quick glance it looks good. The questionmarks are more
>> about how to introduce this new functionality in a safe way and what more
>> is needed that you have not addressed so far.
>>
>>
>> Suggested way forward
>> ------------------------------
>>
>> I think that one approach that would make it easier to include this kind
>> of functionality soon would be to make minimal changes to the existing
>> distribution code and only add or change so that it is possible to support
>> heterogenous protocols with code that initially can live as a separate
>> extension that don't need to be part of the OTP distro.
>> In this way the functionality can be further developed and used together
>> with an ordinary OTP distro (unpatched) and can easily be included later
>> (hopefully within a year).
>>
>> Maybe you think that you already have done those minimal changes, but I
>> suggest you take another look and see if it is possible to find a way to
>> make minimal or now changes to net_kernel and epmd etc. which we could
>> include and then have the rest as a separate "application"/extension
>> project at github that can be included later.
>>
>> Just some thoughts:
>> Maybe let the old distribution work as before and let the user choose
>> "new_distro" in some way and will only then get to run the new code which
>> allows heterogenous protocols another new EPMD or an EPMD written in Erlang
>> or allow for plugins of different EPMD implementations that can run in
>> parallell. The communication towards EPMD maybe needs to be secure as well
>> and then it might be much easier to implement in Erlang.
>>
>> I (we) are more than willing to discuss more about how to find this
>> minimal patch which we think we can "safely" include and which makes it
>> possible to develop and use the rest as pure extensions to OTP in a first
>> step.
>>
>> Regards Kenneth, Erlang/OTP Ericsson
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140115/2bda53fd/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Re: Add net_kernel and epmd support for multiple simultaneous distributed transport protocols

DeadZen-2
What is the status of this?

thanks,
Pedram

On Wed, Jan 15, 2014 at 4:58 AM, Kenneth Lundin
<[hidden email]> wrote:

> Hi Serge,
>
> See embedded comments at the end.
>
>
> On Thu, Jan 9, 2014 at 9:26 PM, Serge Aleynikov <[hidden email]> wrote:
>>
>> Kenneth,
>>
>> Thank you for the thorough response! Your reasoning is appealing and I'd
>> like to engage in the discussion on how we can move on to include this
>> functionality in the distribution, as I believe the community will benefit
>> greatly from being able to run an Erlang node listening on multiple
>> transports concurrently.
>>
>> The changes in the patch (https://github.com/erlang/otp/pull/121) cover
>> the following areas:
>>
>> 1. Extension of the EPMD distributed protocol (here we can safely add new
>> set of commands while being fully backward compatible)
>>     erts/doc/src/erl_dist_protocol.xml
>>
>> 2. Modification of the EPMD daemon to support the new protocol version and
>> to keep track of the multiple protocols/ports per node (this is also done in
>> a backward compatible way. Nodes supporting new protocol version communicate
>> using new spec, and old nodes communicate using old spec)
>>     erts/epmd/src/epmd.h
>>     erts/epmd/src/epmd.c
>>
>> 3. Modification of the EPMD command-line tool to talk to the local EPMD
>> daemon using the new protocol version (the command-line tool uses new
>> protocol version. This is reasonable, since it's installed together with the
>> version of VM supporting the new EPMD protocol features)
>>     erts/epmd/src/epmd_cli.c
>>     erts/epmd/src/epmd_cli.c
>>     erts/epmd/src/epmd_int.h
>>     erts/epmd/src/epmd_srv.c
>>
>> 4. Updates of the UDS distribution example code. I believe the example in
>> the current release is outdated (I was unable to compile it), but I patched
>> it anyway to illustrate the usage of the new protocol)
>>     lib/kernel/examples/uds_dist/src/dist_selector.erl
>>     lib/kernel/examples/uds_dist/src/uds_dist.erl
>>     lib/kernel/examples/uds_dist/src/uds_server.erl
>>
>> 5. Change of the net_kernel transport pluggable architecture to allow
>> support of the new EPMD protocol.
>> 5.1 Net_kernel support for the new protocol.
>> 5.2 TCPv4 support of the new protocol
>> 5.3 TCPv6 support of the new protocol
>> 5.4 TLS support of the new protocol
>>     lib/kernel/src/net_kernel.erl
>>     lib/kernel/src/dist_util.erl
>>     lib/kernel/src/inet6_tcp_dist.erl
>>     lib/kernel/src/inet_tcp_dist.erl
>>     lib/kernel/src/net_kernel.erl
>>     lib/ssl/src/inet_tls_dist.erl
>>     lib/ssl/src/ssl_tls_dist_proxy.erl
>>     lib/kernel/doc/src/net_kernel.xml
>>
>> It seems to me that we could roll it out in two phases:
>>
>> 1. Implement 1,2,3 in the first phase.  This would allow to deploy a
>> version with EPMD supporting old and new protocols.
>> 2. Implement changes to net_kernel and transports (4,5) to be able to talk
>> to new EPMDs
>>
>> If agreed, I can break up my patch in two, corresponding to this plan.
>>
>> What do you think?
>
>
> I think it is a good idea to roll out this in 2 or more phases but I think
> we need think a bit more about this before we can give a more feedback on
> exactly what to include in the different phases.
>
> Will be back with more comments/suggestions soon.
>
> Regards Kenneth
>>
>>
>> Serge
>>
>>
>>
>> On Thu, Jan 9, 2014 at 10:53 AM, Kenneth Lundin <[hidden email]>
>> wrote:
>>>
>>> On Fri, Jan 3, 2014 at 4:30 PM, Serge Aleynikov <[hidden email]>
>>> wrote:
>>>>
>>>> I'd like to inquire the status of the following pull request:
>>>> https://github.com/erlang/otp/pull/121
>>>>
>>>> Has it been reviewed?
>>>>
>>>> Thanks!
>>>>
>>>> Serge
>>>>
>>> Hi Serge,
>>>
>>> We have discussed your contribution at the OTP technical board and here
>>> are the results:
>>>
>>> Inclusion in OTP
>>> -----------------------
>>>
>>> Your patch touches many source files which are central for the Erlang
>>> distribution and we feel it would require quite a lot of work from our side
>>> as well to assure that nothing in the current distribution gets broken or
>>> incompatible. It would also require quite deep involvement from us giving
>>> more detailed feedback regarding interfaces, semantics etc. We can not
>>> prioritize this at the moment so we will not include your contribution now
>>> (which means REJECT for now).
>>>
>>> But we really want to add this kind of functionality and want to
>>> encourage you (and others) to continue the good work in this area for
>>> possible inclusion in OTP at a later stage. See more info and thoughts
>>> below.
>>>
>>>
>>> General thoughts
>>> -----------------------
>>>
>>> Enhancing/extending the Erlang distribution to support heterogenous
>>> communication protocols is something we have discussed many times and it is
>>> something that we really would like to have.
>>>
>>> 1) We would like a plugin architecture where different transport
>>> protocols can be easily plugged in without having to change the basic Erlang
>>> distribution or the VM.
>>>
>>> 2) It should be possible to run different protocols towards different
>>> nodes
>>>
>>> 3) should be possible to have different timeouts (NET_TICK_TIME) per
>>> connection
>>>
>>> 4) interesting protocols would be UDS, TCP, TLS over TCP, SCTP, ...
>>>
>>> 5) it should be possible to look up nodes in different ways and maybe not
>>> only via contacting epmd on the host name which is part of the node name.
>>> I.e having the hostname as part of the node name is not always what you
>>> want, depending on protocol to use.
>>>
>>> ....
>>>
>>> Your specific contribution
>>> -----------------------------------
>>> In your pull request you have implemented fully or partly 1,2, 4, and we
>>> see it as a good start.
>>>
>>> A general comment is that the diffs are showing differences on many
>>> places in the code where you actually haven't changed anything except tabs,
>>> line breaks and spaces. This makes it more difficult to sort out what you
>>> have changed and added. We would like a clean diff without unnecessary
>>> touches lines which has no relevance for the new function. If a formatting
>>> change is needed or suggested it should be a separate commit/pull request.
>>>
>>> Regarding details in your code we have not had the time to take a deeper
>>> look but from a quick glance it looks good. The questionmarks are more about
>>> how to introduce this new functionality in a safe way and what more is
>>> needed that you have not addressed so far.
>>>
>>>
>>> Suggested way forward
>>> ------------------------------
>>>
>>> I think that one approach that would make it easier to include this kind
>>> of functionality soon would be to make minimal changes to the existing
>>> distribution code and only add or change so that it is possible to support
>>> heterogenous protocols with code that initially can live as a separate
>>> extension that don't need to be part of the OTP distro.
>>> In this way the functionality can be further developed and used together
>>> with an ordinary OTP distro (unpatched) and can easily be included later
>>> (hopefully within a year).
>>>
>>> Maybe you think that you already have done those minimal changes, but I
>>> suggest you take another look and see if it is possible to find a way to
>>> make minimal or now changes to net_kernel and epmd etc. which we could
>>> include and then have the rest as a separate "application"/extension project
>>> at github that can be included later.
>>>
>>> Just some thoughts:
>>> Maybe let the old distribution work as before and let the user choose
>>> "new_distro" in some way and will only then get to run the new code which
>>> allows heterogenous protocols another new EPMD or an EPMD written in Erlang
>>> or allow for plugins of different EPMD implementations that can run in
>>> parallell. The communication towards EPMD maybe needs to be secure as well
>>> and then it might be much easier to implement in Erlang.
>>>
>>> I (we) are more than willing to discuss more about how to find this
>>> minimal patch which we think we can "safely" include and which makes it
>>> possible to develop and use the rest as pure extensions to OTP in a first
>>> step.
>>>
>>> Regards Kenneth, Erlang/OTP Ericsson
>>
>>
>
>
> _______________________________________________
> erlang-patches mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-patches
>
_______________________________________________
erlang-patches mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-patches