|
Note 6
Bob Thomas remembers: I joined BBN shortly after the ARPANET had been developed. At the time I think there were about half a dozen IMPs in the ARPANET and fewer than 8 or 9 host computers on the net. Over the next few years the network grew substantially. I was hired to work on an ARPA contract, part of whose focus was to investigate innovative uses of the ARPANET -- that is, uses other than remote terminal access, file transfer, remote job entry. At the time some of the department I joined at BBN were working on a Dept of Transportation project to develop a simulator for air traffic which was to be used to study various algorithms for controlling the traffic in terminal areas (around airports) and the larger (enroute) areas airplanes traversed from origin to destination. (In those days a flight across the US would involve a number of such areas (called air spaces); 2 terminal air spaces and multiple enroute spaces. The simulator itself allowed a "user" to define air traffic through an air space in terms of the aircraft, time of departure, flight plan, etc.
One of the things I explored was "distributing" the air traffic simulation across computers on the net where the "unit of distribution" was an air space. That is, the simulation of different air spaces would/could be performed by different computers attached to the network. As a simulated aircraft traveled from the origin of its flight to its destination responsibility for simulating it would pass from computer to computer. This required that the computers simulating such a flight interact by means of the network to pass responsibility for simulating the flight from one to the other (passing parameters such as the aircraft's air speed, direction, altitude and flight plan from one computer to the other). After getting that working I thought it would be interesting to explore moving parts of the distributed simulation from computer to computer without interrupting the simulation itself. To do that a part (A) of the computation would have to move from one machine to another and its peers (say, parts B, C and D) would need to know it had moved and to which network computer so that the simulation could continue uninterrupted (with parts A, B, C and D properly interacting).
As a first step I decided to write a program that performed a simple task capable of moving itself from computer to computer as it performed that task. To do this, in addition to moving itself from computer to computer the program also had to move its "computational state" so that when it arrived at its destination it could resume the computation from the point at which it was prior to the move, thereby enabling it to perform its task correctly.
I called this program Creeper. It would move around the network among DEC PDP-10 computers running the Tenex operating system. There were a number of variants of the program, one of which printed the message "I'm Creeper, catch me if you can". If I recall correctly, Ray Tomlinson wrote a program called Reaper which would track down and destroy Creeper.
After getting the technique for moving from machine to machine working with Creeper I modified the air traffic control simulation program to use the technique so that its parts could migrate from machine to machine around the network without disrupting the ongoing air traffic simulation (other than to cause a slight "pause" in the interactions between the part that moved and its peers).
One of the things I explored was "distributing" the air traffic simulation across computers on the net where the "unit of distribution" was an air space. That is, the simulation of different air spaces would/could be performed by different computers attached to the network. As a simulated aircraft traveled from the origin of its flight to its destination responsibility for simulating it would pass from computer to computer. This required that the computers simulating such a flight interact by means of the network to pass responsibility for simulating the flight from one to the other (passing parameters such as the aircraft's air speed, direction, altitude and flight plan from one computer to the other). After getting that working I thought it would be interesting to explore moving parts of the distributed simulation from computer to computer without interrupting the simulation itself. To do that a part (A) of the computation would have to move from one machine to another and its peers (say, parts B, C and D) would need to know it had moved and to which network computer so that the simulation could continue uninterrupted (with parts A, B, C and D properly interacting).
As a first step I decided to write a program that performed a simple task capable of moving itself from computer to computer as it performed that task. To do this, in addition to moving itself from computer to computer the program also had to move its "computational state" so that when it arrived at its destination it could resume the computation from the point at which it was prior to the move, thereby enabling it to perform its task correctly.
I called this program Creeper. It would move around the network among DEC PDP-10 computers running the Tenex operating system. There were a number of variants of the program, one of which printed the message "I'm Creeper, catch me if you can". If I recall correctly, Ray Tomlinson wrote a program called Reaper which would track down and destroy Creeper.
After getting the technique for moving from machine to machine working with Creeper I modified the air traffic control simulation program to use the technique so that its parts could migrate from machine to machine around the network without disrupting the ongoing air traffic simulation (other than to cause a slight "pause" in the interactions between the part that moved and its peers).
Copyright 2012-2022 @ xbbn.org under a Creative Commons license.
