Help-Site Computer Manuals
  Algorithms & Data Structures   Programming Languages   Revision Control
  Cameras   Computers   Displays   Keyboards & Mice   Motherboards   Networking   Printers & Scanners   Storage
  Windows   Linux & Unix   Mac

a class that provides for the creation of Scooby mobile agent environments.

"Mobile::Location" - a class that provides for the creation of Scooby mobile agent environments.


``Mobile::Location'' - a class that provides for the creation of Scooby mobile agent environments (aka Location, Site or Place).


4.0x (the v1.0x, v2.0x and v3.0x series were never released).


use Mobile::Location;

my $location = Mobile::Location->new;





1. Never, ever run a Location as 'root'. If you do, this module will die. Running as 'root' is a serious security risk, as a mobile agent is foreign code that you are trusting to execute in a non-threatening way on your computer. (Can you spell the word 'v', 'i', 'r', 'u', 's'?!?)

2. The Mobile::Location class executes mobile agents within a restricted environment. See the Ops argument to the new method, below, for more details.

3. Never, ever run a Location on the same machine that is acting as your keyserver (it's a really bad idea, so don't even think about it).


Part of the Scooby mobile agent machinery, the Mobile::Location class provides a convenient abstraction of a mobile agent environment. Typical usage is as shown in the SYNOPSIS section above. This class allows for the creation of a passive, TCP-based mobile agent Location.


Simply create an object of type Mobile::Location with the new method. To start a sequential server, use the start_sequential method. To start a concurrent server, use the start_concurrent method.

Construction and initialization

Create a new instance of the Mobile::Location object by calling the new method:

my $location = Mobile::Location->new;

Optional named parameters (with default values) are:

Debug (0) - set to 1 to receive STDERR status messages from the object.

Port (2001) - sets the protocol port number to accept connections on.

Log (0) - set to 1 to instruct the Location to log the received mobile agent to disk prior to performing any mutation. The name of the logged agent is ``last_agent_PID.log'', where PID is the process identifier of the Location. On sequential Locations, the PID is always the same value for each received agent. On concurrent Locations, the PID is the PID of the child process that services the relocation/re-execution, so it is always different for each received agent (so watch your disk space). It is often useful to switch this option on (by setting Log to 1) when debugging. Note that the received mobile agent persists on the Location's local disk storage.

Ops ('') - add a list of Opcodes to the Opcode mask that is in effect when the mobile agent executes. Study the standard Opcode and Ops modules for details on Opcodes and how they are set. One way to secure your Location against attack is to ensure that the Opcodes in effect while a mobile agent executes are ``safe''. This is NOT an easy task, as protecting the mobile agent environment from malicious mobile agents is never easy. Note that the default set of Opcodes in effect are enough to allow the relocation mechanism to execute. NOTE: if the mobile agent uses a operation not allowed by the Opcode mask, it is killed and stops executing. The Location continues to execute, and waits passively for the next mobile agent to arrive. The default set of enabled Opcodes is restrictive. Provide a space-delimited list of Opcodes to this argument to add to the list of allowed opcodes. NOTE: this functionality is currently disabled due to conflicts/incompatibilities with the current version of Crypt::RSA (version 1.50).

Web (1) - turns on the HTTP-based Monitoring Service running on port 8080 (HTTP_PORT), thus enabling remote monitoring of the Locations current status. It also logs interactions with this Location into 'location.log' (LOGFILE). Set to 0 to disable this behaviour.

Note that any received mobile agent executes in a directory called ``Location'', which will be created (if needs be) in the directory that houses this Location. Any ``logs'' are also created in the ``Location'' directory.

A constructor example is:

my $place = Mobile::Location->new( Port => 5555, Debug => 1 );

creates an object that will display all STDERR status messages, and use protocol port number 5555 for connections. Logging of received agents to disk is off. The standard Opcode mask is in effect. And logging to disk is on, as is the HTTP server.

When the Location is constructed with new, a second network service is created, running at protocol port number Port+1. In the example above, this second network service would run at protocol port number 5556. When sent the names of a set of Perl classes (e.g., Data::Dumper, HTTP::Request, Net::SNMP and the like), this service checks to see if the classes are available to the locally installed Perl installation. This allows Devel::Scooby to determine whether or not relocation is worthwhile prior to an attempted relocation. The Devel::Scooby module tries to determines the list of classes used by any mobile agent and communicates with this second network service ``in the background''. This all happens automatically, so the mobile agent programmer does not need to worry about it, as Devel::Scooby only complains when a module does not exist on a remote Location. That said, the administrator of the Location does need to be aware of this second network service. To confirm that the Location and the second network service are up-and-running use the netstat -an command-line utility (on Linux). The two ``listening'' services should appear in netstat's output.

Note: If a Location crashes (or is killed), the second network service can sometimes keeps running. After all, it is a separate process (albeit a child of the original). Trying to restart the Location results in an ``bind to address failed'' error message. Use the ps -aux command to identify the Perl interpreter that is executing and kill it with kill -9 pid, where pid is the process ID of the child process's Perl interpreter.

Class and object methods

Start the location as a passive server, which operates concurrently. Once connected to a client, the server forks another process to receive and continue executing a mobile agent. This is the preferred method to use when there exists the potential to have an agent execute for a long period of time.

Start the location as a passive server, which operates sequentially. Once connected to a client, the server sequentially processes the receipt and continued executing of a mobile agent. This is OK if the agent is quick and not processor intensive. If the agent has the potential to execute for a long period of time, use the start_concurrent method instead. This may also be of use within environments that place a restriction on the use of fork.

Internal methods/subroutines

The following list of subroutines are used within the class to provide support services to the class methods. These subroutines should not be invoked through the object (and in some cases, cannot be invoked through the object).

Takes a filename and line number, then combines them with the current time to produce a random, unique label.

Given a list of module names, checks to see if the Location's Perl system has the module installed or not.

Used by the new constructor to spawn the Port+1 network service which listens for a list of modules names from a mobile agent, then checks for their existence within the locally installed Perl system.

Given a socket object (and the instances init data), service the relocation of a Scooby mobile agent.

Creates a PK+ and PK- value for the server, storing the PK+ in the keyserver, and the PK- in the object's state.

_logger and _logger2
Logs a message to the LOGFILE.

Builds the INDEX.HTML page for use by the HTTP-based Monitoring Service.

Builds the CLEARLOG.HTML page for use by the HTTP-based Monitoring Service.

Starts a small web server running at port 8080 (HTTP_PORT), and uses the two ``_build_*'' routines just described.

Creates a subprocess and starts the web server.


The Mobile::Executive module (for creating mobile agents), as well as Devel::Scooby (for running mobile agents).

The Scooby Website:


Paul Barry, Institute of Technology, Carlow in Ireland,,


Copyright (c) 2003, Paul Barry. All Rights Reserved.

This module is free software. It may be used, redistributed and/or modified under the same terms as Perl itself.