[erlang-questions] Controlled interaction of two erlang distributed networks

[Kenji Rikitake]

Disclaimer: I am not insisting to change Erlang rpc module as of now.
The rpc module model works fine for the intended usage.  (What I'm
writing may be on a different track from the beginning of this thread.)

I want to have something additional.

In the message <7702c0610908270521p3eb6054ewe380b3962dad66ea@REDACTED>
dated Thu, Aug 27, 2009 at 10:21:25PM +1000,
Richard Andrews <bflatmaj7th@REDACTED> writes:
> > * with restricting the usage of TCP connection between two BEAMs to only
> > one well-known destination port;
> 
> inet_dist_listen_min + inet_dist_listen_max does this.

About rpc with inet_dist, true.  This should be configured for all BEAMs
individually though.  

Question: Why not only one destination port number is sufficient?

> > * preferably being able to forwarded through proxies (i.e. the
> > addressing mechanism of BEAMs does not depend on DNS, IP addresses, or
> > port numbers); and

> It would be nice if nodes did not keep opening more and more TCP
> connections between the same two nodes in different directions.

Agreed.

Why not overlaying multiple Erlang node connections between two IP hosts
into one TCP (or SCTP if needed) connection?

> Distribution over SCTP might solve this issue. Does this exist?

I've never heard of Erlang SCTP distribution.  Surely an interesting
project to try out.

> > * running everything within a BEAM (and linked-in drivers) without
> > anything like epmd

> The directory (epmd) needs to be in a predictable location and it
> cannot be in a node as it must monitor those. I do dislike the inet
> and ssl helper processes that hang off beam nodes; although having
> them separate has helped me debug some problems.

I am not claiming to remove epmd functionality for rpc.  I'd rather want
it in an Erlang BEAM or something directly controllable from BEAM.

One long-time argument for epmd: at least the source port address with
bind() system call should be freely specified other than
INADDR_ANY. I've seen this argument repeatedly on the list and I wonder
why this has not been implemented yet.  Binding to INADDR_ANY is the
least preferable choice, especially a host has multiple addresses bound
into a network interface.

> > will open a new opportunity for Erlang to become a practical system for
> > monitoring/controlling distant systems over Internet. ?This is a
> > challenging but an interesting project.
> 
> You may be trying to re-cast erlang distribution for something it was
> not intended to do.

Disclaimer repeated: I am not trying to re-cast the current rpc
module-based distribution.

I need something in Erlang to safely monitor/control/manipulate/whatever
each other between BEAMs across the Internet.

Read Dave Smith's paper as well.

>   Rich

Kenji Rikitake