![[Contents]](../manuals/icons/contents.gif){kind=icon}
![[Prev]](../manuals/icons/prev.gif){kind=icon}
![[Next]](../manuals/icons/next.gif){kind=icon}
Knowbot Programs are mobile agents intended for use in widely distributed systems like the Internet. The most distinguishing characteristic of mobile agents is that they can move their execution from one host to the next. The Knowbot Operating Environment provides the infrastructure for these mobile programs. The current version, a research prototype, uses the object-oriented prototyping language Python and Xerox PARC's Inter-Language Unification (ILU) distributed object system.
Mobile agents can be used for many purposes. Amongst other uses, we expects that Knowbot Programs will be used for personalized web searches, for remote database queries, and for distribution of disseminations of digital objects while obeying terms and conditions of use (including collection of fees and restrictions on who can view the dissemination).
Two important motivations for using Knowbot Programs are performance and flexibility. An application can improve performance by trading computation at a remote site against bandwidth and latency. A program that sifts through a large database may be much more efficient if it can execute near the data rather than far away from it.
Knowbot Programs also improve the flexibility of distributed systems. Client applications can define custom services that were not forseen by the developers of the system's static interface. The basic system interface can be made simple and fast, allowing clients to build application-specific interface on top of it. This flexibility accelerates the pace of innovation; new ideas and application can be quickly tested and deployed.
The Knowbot Operating Environment (KOE) consists of any number of hosts that run mobile programs and several services that connect the service stations and the users that launch mobile programs. A mobile agent compatible with the KOE architecture is called a Knowbot Program (KP). The hosts where KPs run are called Knowbot Service Stations (KSS). Client tools are used for KP submission, and to monitor and control KP and KSS behavior.
The most important concept in the KOE are Knowbot Programs. The current architecture is prepared for the support of multiple programming languages, but the initial release only supports Python. We expect that the design of support for KPs written in Python carries over to other languages, like Java.
When KP is submitted to a service station, a subprocess is forked to execute the KP. In order to protect the service station (and other KPs), the KP is restricted in the operations it may execute. For instance, the KP has no direct access to the local file system or networking primitives. These restrictions are enforced by the supervisor, a KSS component that executes in the same process as the KP. The supervisor is the only language-specific component. (Note that even though the restricted execution environment is implemented, the current release of the system is not totally safe; see Security Issues.)
A KP is submitted to a KSS in some executable form. For Python programs, this means one or more source code modules; these are automatically compiled to internal bytecode by the Python interpreter. When we extend the system with support for Java, the submission of a KP written in Java would consist of Java .class files. (Submission of Python bytecode files is currently not safe, because the Python interpreter does not yet have a bytecode verifier.)
A KP can decide to migrate to another KSS. It invokes the migrate() operation provided by the supervisor, specifying the name of the destination KSS as argument. The supervisor then serializes the KP object and submits the KP's source code and serialized state to the destination service station. Migration is similar to an initial KP submission except for the presence of the object state in the submission. Once the submission has been accepted, the original KP exits. There is also a clone() operation, which submits a new KP to the destination service station but does not exit the original one.
The current system does not capture and submit the entire run-time state of a KP on migration -- only a designated object and all objects reachable from it. The current call stack is not captured, and the migrated program is executed from its main entry point. We are considering modifications to the Python interpreter to support migrating the entire run-time state.
In addition to the program code and the optional program state (for migration), a KP submission can contain arbitrary data. This data, called the suitcase, is structured like a virtual file system. The KP can read and write the contents of the suitcase, and the suitcase is automatically transferred on migration. A KP's suitcase is not accessible to other KPs; suitcases are not shared between clones (i.e. the clone receives a copy of the original KP's suitcase).
In the future, the program code and state will probably become part of the suitcase, instead of being separate components of the KP submission. This more unified model gives a KP access to its own code and state, just like an ordinary program may be able to find its own source on the file system.
The KOE submission mechanism supports a way to specify arbitrary metadata items for a KP, but currently looks only at a small number of the specified metadata items. These serve to specify options for the execution of a KP, such as program arguments, where to connect its standard I/O streams, and the programming language used (in the future, when more than language is supported). There are also metadata items specifying the name of the main module and class. In general, the metadata is supplied automatically by the submission tools, based on information provided by the user. Metadata is automatically copied when a KP migrates or creates a clone of itself.
The KOE implementation also includes a distributed, hierarchical namespace used to name KSSs and KPs. The namespace allows location-independent naming of service stations. Each service station manages its own portion of the namespace. The top levels of the namespace hierarchy are replicated in separate "Worldroot" servers (not dependent on KSS nodes). The replication algorithms used by the Worldroot servers favor accessibility over consistency.
While Knowbot Programs are the most important concept in the KOE, the Knowbot Service Station makes up the bulk of the KOE software. The software that turns a computer into a Knowbot Service Station is called the Knowbot Operating System (KOS). The KOS runs on top of standard workstation software; currently, it requires a Unix workstation but in the future it will run on Windows as well. The KOS consists of the following components:
To get started, you should install the KOE software and then read the quick start guide to learn how to run a service station. The KOE distribution includes many simple test programs, some examples, and a few larger demonstration applications.