mobile processes

[Tony Rogvall]

Vlad Dumitrescu wrote:

> The question raised earlier today made me think about the topic, and
> there is one detail I wonder about: the actual move of a
> process/application to another node is not a big problem. Not with
> Erlang, anyway... But how do already running linked clients switch to
> the new node, unless they expect and can handle this move? In a
> perfect world, the move would be transparent to the clients... Are
> there any solutions that I overlooked? regards,Vlad

The problem with relinking to the original node is solvable, but need
some system updates.

I think that even to move any process (not only gen_servers and the
like) is (nearly) solvable.

One problem arise when you have stored local information in the process
i.e Node = node(), then today the Node variable will contain an atom
that is not easy to rewrite.

An other problem is when you sent the process id to processes on other
nodes. When the original node goes down there is no one on the original
node to do message "redirects". I have seen solutions where you can
query the network (broadcasts) for new locations and store
translations at the senders. For WAN like networks it is not that easy.
(If you think in terms of mobile IP, there must exist a Home node to be
able to respond to reregistrations of new locations!)

Yet an other big problem are the ports, if we assume that the original
node is up running and the distribution protocol is updated to handle
remote port calls (or messages) then relinking port whould be doable as
well.
Moving ports is not that easy :-)
If all used ports (programs/loadable drivers) where written to support a
move then perhaps.

In other words. In theory this is totally impossible to do in a generic
way, but in practise it depends up to the application.

/Tony

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tony.vcf
Type: text/x-vcard
Size: 328 bytes
Desc: Card for Tony Rogvall
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000928/a295ae11/attachment.vcf>