C nodes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

Vlad Dumitrescu-3
Hi

This time I think I have more down-to-earth question. :-)

Why can't C or Java nodes be fully equivalent to Erlang nodes? (from the point of view of an Erlang node connecting to them)

/Vlad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20010302/e6041ac2/attachment.html>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

tobbe

> Why can't C or Java nodes be fully equivalent to Erlang nodes? (from
> the point of view of an Erlang node connecting to them)

Because, some std.applications relies on that all nodes in nodes/0
behaves as a "distributed Erlang node".

Cheers /Tobbe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

Vlad Dumitrescu-3
> > Why can't C or Java nodes be fully equivalent to Erlang nodes? (from
> > the point of view of an Erlang node connecting to them)
>
> Because, some std.applications relies on that all nodes in nodes/0
> behaves as a "distributed Erlang node".

Can I interpret this as saying that what would be needed is a sound infrastructure for a C (or something other language) node (warranting that it will behave just like a regular Erlang node)? That might eliminate the need for many ports, since they might be implemented as full nodes...

/Vlad




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

Raimo Niskanen-3
Vlad Dumitrescu wrote:

>
> > > Why can't C or Java nodes be fully equivalent to Erlang nodes? (from
> > > the point of view of an Erlang node connecting to them)
> >
> > Because, some std.applications relies on that all nodes in nodes/0
> > behaves as a "distributed Erlang node".
>
> Can I interpret this as saying that what would be needed is a sound infrastructure for a C (or something other language) node (warranting that it will behave just like a regular Erlang node)? That might eliminate the need for many ports, since they might be implemented as full nodes...
>
> /Vlad

I guess so, but there is quite some things that a node must do to be a
"real" erlang node. For a short list right out of the head: rpc, file,
global, global_group, dist_ac, application, application_controller.
There are probably a lot more.

/ Raimo Niskanen, Ericsson UAB, Erlang/OTP


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

Ulf Wiger-4
On Sat, 3 Mar 2001, Raimo Niskanen wrote:

>I guess so, but there is quite some things that a node must do to be a
>"real" erlang node. For a short list right out of the head: rpc, file,
>global, global_group, dist_ac, application, application_controller.
>There are probably a lot more.

Rpc? That would probably not be required. You would only want to
use rpc:call(M, F, A) if you know exactly what module is loaded
on the other node - most likely that it is the very same module
that is loaded in yours.

File? Yes, perhaps.

Global? global_group? Naah. I think these two need to be rethought
anyway. After that, it might not be too impossible to include a
C node in the global name space.

Dist_ac? Again, you would only use that if you think you can start
applications on the other node, and these are in fact the Erlang
applications that you know and love.

I think what is really needed is a framework for specifying
distributed protocols and handling unsupported services. We may want
to have this between Erlang nodes as well. In most applications so
far, the networks of Erlang nodes have been pretty homogeneous, often
with the very same boot script executing on all nodes. I think many
will want to depart from that in the future.

This is also good from another perspective: it forces us to be more
formal about the traffic between nodes, and makes it easier to
maintain compatibility across versions, as well as reason about
real-time and robustness characteristics.

/Uffe
--
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

C nodes

Vlad Dumitrescu-3
> >I guess so, but there is quite some things that a node must do to be a
> >"real" erlang node. For a short list right out of the head: rpc, file,
> >global, global_group, dist_ac, application, application_controller.
> >There are probably a lot more.

> I think what is really needed is a framework for specifying
> distributed protocols and handling unsupported services. We may want
> to have this between Erlang nodes as well. In most applications so
> far, the networks of Erlang nodes have been pretty homogeneous, often
> with the very same boot script executing on all nodes. I think many
> will want to depart from that in the future.

I agree with Ulf here. As a matter of fact, as I see things, there are two different issues: the Erlang VM and the network/distribution mechanism.

To me, they seem only loosely connected. It should be possible to completely split the two apart and then for example use something else than Erlang to actually run the code. Of course, not with the same elegance and simplicity, but the big benefit would be that ports would be replaced by true nodes and the clumsy communication mechanism with ports would be replaced by TCP/IP (as default). I think that would only add to the elegance of the system.

Of course, that would lead to heterogenous networks, with nodes that might only be able to run a single process, or don't have the same modules available, but in a truly distributed world, that should be closer to the reality than not...

In conclusion, is it possible (without rewriting the whole system) to separate the Erlang VM from the underlying networking runtime, and use thet runtime as a base for non-Erlang nodes?

cheers, Vlad






Loading...