gen_server:call internal format & OTP compatibility

[Rickard Green]

On Wed, Oct 13, 2021 at 10:56 PM Roberto Ostinelli <ostinelli@REDACTED>
wrote:

> All,
> I'm writing a distributed library that I would like to be compatible with
> clusters running multiple OTP versions. I am aware that backwards
> compatibility for the distribution protocol is only promised for two major
> releases in either direction, but that's already pretty significant.
>
> Therefore, for instance maybe I should avoid using gen_server:call/2,3 to
> call processes running on a different node with something like
> gen_server:call({?MODULE, RemoteNode}, Message).
>
> My thinking is that the internal call message format of gen_server is an
> internal implementation detail subject to change, thus it might be
> incompatible on different OTP versions, and if this is the case then the
> previous call would fail.
>
>
However, it's a pity to not use the robust usage of standard API calls. On
> the other hand, it does not look like this message format has changed
> recently, so maybe I'm just overthinking it and should just use
> gen_server:call/2,3 without fear of breaking anything.
>
> I'd like to hear some thoughts, if someone would like to chime in.
>
> Thanks,
> r.
>

We don't make changes in the gen_server protocol which will cause failures
to communicate with OTP nodes of +-2 releases. Communicating with nodes +-3
releases might fail. This is also the case if you implement your own
protocol if it utilize the Erlang distribution. That is, I see no point in
implementing your own protocol unless you also stop using the Erlang
distribution all together. It is not safe to connect Erlang nodes over the
Erlang distribution that differs more than 2 releases. Safe in the sense
that you might get communication failures in other subsystems even though
your protocol might work.

Regards,
Rickard
-- 
Rickard Green, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20211014/2ecde24a/attachment.htm>