Travelling software. Is that a concept?

Question

Hi!

I would like to ask if there existed a program, which were intended to travel (for example following some physical forces) across the planet, possibly occupying and freeing computational resources/nodes. Literally that means that some agent-based system is just regularly changing it's location and (inevitably to some extent) configuration.

An example would be: suppose you have external sensors, and free computers - nodes - across the space; would it make sense to self-replicate agents to follow the initializers from sensors, but in such restrictive manner that the computation is only localized at where the physical business is going on.

I want to stress that this question is just for 'theoretical' fun, cause I cannot see any practical benefits of the restrictions mentioned, apart from the optimization of 'outdated' (outplaced?) agent disposal. But maybe it could be of some interest. Thank you!

EDIT: It's obvious that a virus is fitting example, although the deletion of such agents is rarely of concern of the developers. More precisely, I'm interested in 'travelling' software - that is, when the count (or at least order) of the agents is kind of constant, and it's just the whole system who travels.

Answer 1

Anything that could be done well by a moving program seems like it might be done better by a widely distributed one.

Answer 2

The research community in obiquituous computing does a lot of work on those sort of problems.

For example, if you are working on a document you get it displayed with a particular interaction modality based on the devices around you. If you are communicating, same thing. You could argue that many location-based computing applications do something similar. The department of defense was sponsoring some research on context-sensitive automated assistants, etc.

If we assume a globe-spanning distributed "cloud", then the location of where computing actually takes place will be unknown and transparent for you. All that matters is the context. Considering that GPS-enabled devices are becoming ubiquitous and that video processing is becoming cheaper (my $50 camera can spot faces), then the quality of the context is certainly increasing. In that sense, many programs already manifest the vision you're describing.

Answer 3

Yes, if you have a processing delivery network across the globe and some sort of script migration, you could sign in and have the script migrate to a node near you, based on some sort of geolocation.

Answer 4

I have never worked with it myself, but the programming language Obliq seems to be geared to such kind of computations. From the Obliq paper (page 12) referenced on this web page:

Obliq addresses a very dynamic form of distributed programming, where objects can redirect their behavior over the network, and where computations can roam between network sites.

Answer 5

Maybe the master of a Botnet is close what you are looking for? Obviously very similar to the "virus" answer above: the difference being that while viruses usually 'replicate, spread, do a preprogrammed inconvenient thing,' a botnet is more of a 'take control of your machine for a future, usually nefarious, but dynamic purpose.' I think the hosts (your "agent") can more easily change with a botnet too.

Answer 6

I believe what you are looking for is called Mobile Agents.

BTW: I don't believe a virus qualifies. One of the defining characteristics of a virus is that it cannot travel on its own but depends on a human user to spread it. Worms would qualify, though.

Answer 7

This, perhaps indirectly, is one of the tenets behind Jini. In this case, arguably, it's a matter of downloading drivers. But since it's Java based, the concept of portable code moving from device to device is one of the core philosophies of the system.

Now, to that end, this code does not "move" per se, but rather it gets copied. It doesn't "leave" the server.

But you can see, specifically with Java, that getting the basics up of starting with an empty JVM and some kind of shell, it would be pretty straightforward to get code to "move" from one JVM to another.

You can see the process like this.

1) System A has application running, with state, and local classes. 2) System B has the "transfer shell" executing on the system. 3) A wants to move the application over to B 4) A pauses the application and serializes its state, could be as simple as the just using stock Java object serialization. This serialized object has a "restart" method. 5) B sets up a ClassLoader that refers to the classes on System A. This class loader will copy classes on request from A to B, then it can store them locally. 6) A sends the serialized application state over to B, who de-serializes it. 7) the ClassLoader on B starts pulling class files over from A, as the application is deserialized 8) Once the object is deserialized, B invokes the "restart" method, and the application continues running. 9) A "forgets" about the application, and B continues running detached from A.

Obviously this is naive, and fraught with potential issues.

But you can see how, particularly with a virtual machine, how something like this can work.

Modern VM architectures are working on this process, and in fact this process, of snapshotting running VMs, moving the images to other machines, and starting them up. The basics of VMs make this "easy".

The Java example is just something you can play with without having to become a virtualization engineer.