Re: erlang nodes interop.

Hi Sverker,

I think the epmd version on 19 node is this:

$ ps x|grep epmd
 5312 ?        S      0:00 /usr/lib/erlang/erts-8.3.5/bin/epmd -daemon

So I think it is of erts version 8.3.5


To make things even more strange..

On this (develoment machine) 24 node does not connect to 19 node

But on a production machine with identical erlang/OTP 19
24 node does not connect to this 19 node .






On Thu, Nov 11, 2021 at 6:39 PM Bogdan Andu <[email protected]> wrote:
>
> it is not a compatibility issue.
> otherwise they would not be able to connect at all.
>
> only that particular case is not working
>
> On Thursday, November 11, 2021, Roberto Ostinelli <[email protected]> wrote:
>>
>> OTP keeps compatibility with releases which are ± 2 versions different. Therefore, even if you were to achieve the node clustering, other things might fail.
>> I would consider using a separate, non-erlang protocol over TCP for communication between nodes with such different versions.
>>
>> Cheers,
>> r.
>>
>> On Thu, Nov 11, 2021 at 11:46 AM Bogdan Andu <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> I have two erlang nodes, NodeA and NodeB.
>>> NodeA is OTP version 19 and NodeB is OTP version 24.1.4.
>>>
>>> The nodes have the same cookie;
>>> and they are both started as sname nodes.
>>>
>>> However, the following happens:
>>> Connecting from NodeB to NodeA always fails.
>>> (Node@B)1> net_kernel:connect_node('Node@A').
>>> (Node@B)2> false
>>>
>>> Eleven if I
>>> Until:
>>> Connecting from NodeA to NodeB always succeeds:
>>> (Node@A)1> net_kernel:connect_node('Node@B').
>>> (Node@A)2> true
>>>
>>> After that, connecting from NodeB to NodeA succeeds:
>>> (Node@B)1> net_kernel:connect_node('Node@A').
>>> (Node@B)2> true
>>>
>>> The same behaviour with net_adm:ping/1 or erlang:set_cookie(/2
>>>
>>> A version 19 erlang node is needed because interoperability with
>>> legacy internal ssl systems andalso other systems in production
>>> depend on OTP 19.
>>>
>>> An OTP  19 node is old enough to support older ssl protocols and
>>> new enough to NOT generate the following error in an otp 24 node:
>>> rejected since it cannot handle ["BIG_CREATION"]
>>>
>>> I need connection from NodeA to NodeB to always succeed
>>> because NodeB is the initiating(client) to NodeA, and
>>> NodeA is a RPC server for NodeB.
>>>
>>> What can be done?
>>>
>>> Thank you,
>>>
>>> Bogdan