[Q] SDNC, some thoughts

Johan Fabry johan.fabry at vub.ac.be
Mon Oct 9 09:44:12 UTC 2000


Jeff Szuhay wrote:

> It occurred to me yesterday that as Squeak gets closer
> to being fully pluggable, some other issues arise:
> 
> 1) imagine multiple VMs running each with their
> own image. How then would/could they communicate?

Having multiple VM's talk to each other is a subject which hals been
discussed at some length in a previous thread, so I suggest you have a
look at the 'IPC and SRP' messages in, for example, the egroups archive
(http://www.egroups.com/messagesearch/squeak?query=IPC%20and%20SRP).

Saves us some typing ;-)

> 2) imagine then these multiple VMs running/communicating
> but not necessarily on the same computer... distributed Squeak.

Having some sort of distributed Squeak is one of the things I am toying
with. A prerequisite here is some sort of higher-level interaction
mechanism between different VM's (higher-level than simple socket
communication) <plug> For example, you could try Remote Message Passing
(http://prog.vub.ac.be/poolmembers/johanfabry/RMP.zip) </plug>

But, you should keep in mind that the transition from multiple VM's on 1
machine to multiple VM's on multiple machines adds the important factor
of partial failures of the system. (A big problem in distributed
systems!) For example: What do we do if one of the machines in the
distributed system crashes?

> 3) imagine one VM running but with multiple images running
> concurrently, or even remotely. The Squeak VM  along the l ines
> of a server app to multiple images.

Having one VM running different images could be more efficient than
multiple VM's, each running one image, but I doubt it would be worthwile
to spend the energy on implementing this. Would it not be nicer to spend
this energy on optimising the VM? This way everbody gains from it.

> 4) imagen then multiple systems each with their own Squeak VM
> servers intercommunicating so that you have a real network OS.
> The SDNC: Squeak Distributed Network Computering.
> Multiple images being processed on multiple systems each inter-
> communicating... possibly even  transparent process sharing or
> load balancing through automatic process migration from VM to
> VM.
> 
> The last scenario seems to me to be the preferred one since it
> appears to me to be most efficient of system resources and would
> allow multiple minimal images to be executed, either on the same
> machine or remotely.

You're touching on mobile agents here, where every agent (for sake of
this discussion, let us define it as an object with its own thread) can
migrate itself (the object's state and its thread) to another machine
whenever it sees fit.

The easiest way for the programmer to program these is the so-called
'strong mobility': at any point of the agent's execution, the execution
can be paused, the agent moved, and the execution unpaused (at the other
host). 

To implement this, you must be able to reify both the object's state,
and its execution stack. Luckily, the Smalltalk debugger does just that,
so at least we know it is possible ... now we only need to adapt it.

An interesting problem here is deciding *when* to migrate an agent, and
*where* to migrate it to. 

Now imagine how you would write software for such a system ... 

<plug>Anyway, all of this (and more) is what a number of people at the
Programming Technology lab are thinking about/working on ...
(http://prog.vub.ac.be/poolresearch/CBorg/index.htm)</plug>

> This also implies, to my little mind, that this would drive the VM
> further into the OS as one of its core services. I'm not to sure that
> tight VM integration with the kernel OS is either feasible or even
> possible on a wide scale.

Not really, IMHO, you can still keep the VM as a separate 'layer' on top
of the OS.

--
"You are more than the sum       Johan Fabry - Johan.Fabry at vub.ac.be
 of what you consume.            Vrije Universiteit Brussel
 Desire is not an occupation."   Programming Technology Lab, Room 10F709
  -- KMFDM                       Pleinlaan 2, 1050 Brussels, Belgium





More information about the Squeak-dev mailing list