Linked Process Protocol

%ents; ]>

Linked Process Protocol Linked Process is a protocol for distributed computing that facilitates the creation of an Internet-scale, general-purpose compute cloud. Any computing device with an Internet connection can consume and/or provide computing resources in a Linked Process cloud. Resource consumption occurs when a device migrates arbitrary code to another device for execution. Linked Process is applicable where it is necessary for a resource consumer to define the means by which a provider's resources are utilized. Linked Process is copyright (c) 2009 by the Los Alamos National Laboratory of the United States Government. Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). xxxx ProtoXEP Standards Track Standards Council XMPP Core XEP-0001 XEP-0004 XEP-0030 XEP-0086 NOT_YET_ASSIGNED Marko Rodriguez marko@markorodriguez.com okrammarko@gmail.com http://markorodriguez.com Joshua Shinavier josh@fortytwo.net parcour@gmail.com http://fortytwo.net 0.0.1 2009-09-18 psa

First draft.

Linked Process is a protocol for Internet-scale, general-purpose distributed computing. With an implementation of this protocol, any computing device with an Internet connection can contribute computing resources to a user-generated compute cloud.

The term computing device is broad and spans particulars such as cell phones, laptops, desktops, servers, supercomputers, etc. In Linked Process, a computing device is anything that maintains a central processing unit (CPU) that can be programmed to execute any desired computation.
The term computing resources is broad and spans particulars such as clock cycles, data sets, software application programming interfaces (APIs), or specialized hardware componets such as cell phone cameras, field-programmable gate array (FPGA) circuits, etc.
The term compute cloud is the collection of all Linked Process enabled devices, their resources, and the Linked Process specific software components defined later in this specification.

Within the category of computing devices, Linked Process makes a distinction between resource consumers (devices making use of non-local computing resources) and a resource providers (devices offering computing resources)Nothing prevents the same device from being a resource consumer in one context and being a resource provider in another.. Linked Process allows a resource consumer to leverage the computing resources offered by a resource provider in anyway deemed appropriate by the resource consumer. This is accomplished by the resource consumer providing/migrating/sending code (i.e. software instructions) to a computer language interpreter maintained by the resource provider. As such, it is up to the resource consumer to define the instructions to be executed by the provider. Given this architecture, resource providing devices in a Linked Process cloud are general-purpose computing sandboxes (i.e. they can be leveraged for computational ends that are defined by a resource consumer).

Linked process is unlike Remote Procedure Call (RPC) and Web Service models, where the means by which resources are consumed are defined apriori by the deployer of the service (in the way of functions/methods that can be remotely executed/invoked). The benefit of this protocol is that computing resources that exist elsewhere on the Internet can be leveraged by code that was not developed/created/inteded by the owner/provider of those resources.

Linked Process was developed to address the following two distributed computing requirements: Internet-scale and general-purpose. These requirements imply yet more requirements which accompany their description below.

Internet-scale: it is required that any device with an Internet connection (from a cell phone to a supercomputer) be able provide/contribute and consume/leverage computing resources in a Linked Process cloud.
- Decentralized: it is required that the computing resources are not necessarily centralized or controlled by any one party.
- Discoverable: it is required that resource providers be discoverable by resources consumers.
- Transient: it is required that devices coming online and offline are gracefully incoporated and removed from the cloud.
General-purpose: It is required that consumers be able to utilize provided resources for any desired purpose.
- Language-agnostic: it is required that the protocol support the migration of code written in any computer language.
- Safe: it is required that the execution of consumer code be conﬁned by permissions clearly specified by the resource providerThere is a tradeoff between "general-purpose" and "safety." It is important to ensure that the integrity of resource providers are not compomised due to malicious or poorly written code..
- Accessible: it is required that computing resources be accessible when permissions allow by ensuring the supported language interpreters provide necessary "low-level" manipulations of such resources.

The introduction discussed the physical devices and the roles that they serve as the hardware infrastructure of a Linked Process cloud. This glossary provides a summary of the entites that yield the software instructure of a Linked Process cloud. The following entities make up the core of the Linked Process protocolThe term entity is a generic term refering to a software component that is involved in a Linked Process cloud.. The naming convention used follows a "rural" themeGiven the rural naming convention, the term cloud could have been substituted by the terms nation or world. However, in order to maintain some connection to the terminology of the distributed computing community, the term cloud was opted for instead the more consistent "earthly" term..

Countryside: an XMPP account that is identified by a bare JID. While the term "account" or "bare JID" could have been used, in order to follow the rural theme, the term countryside was adopted.
Farm: an XMPP client that is identified by a fully-qualified JID. The bare JID of the farm is known as the farm's countryside. Any device running a farm will have an account with an XMPP server. A countryside can host many farms (this facilitates the "clustering" of devices). In general, there exists one farm for every physical device providing computing resources to a cloudNote that this is not required as in some cases, it is useful to run multiple farms on a single device. For example, two farms can have different permissions to resources. The purpose of a farm is to wait for resource consumers to communicate with it in order to spawn/create and compute with virtual machines. A farm also specifies the permissions that a villein has with respect to its provided computing resources
Virtual machine: a computing sandbox/environment that is denoted by an identifier that is internally unique to a farm. A virtual machine is spawned from a farm and can be of any "species" (i.e. computer language). A virtual machine, like a farm, exists on the resource provider's device. Example virtual machine species include JavaScript, Python, Ruby, Groovy, etc. A virtual machine is the means by which a client (known as a "villein") is able to access the computing resources of the device running the virtual machine. In short, a virtual machine is the gateway to the computing resources of the resource provider.
Registry: an XMPP client that is identified by a fully-qualified JID. A registry maintains a list of countrysides (i.e. bare JIDs) that have active farms running on them. The purpose of a registry is to allow countryside owners to advertise themselves. A registry monitors all the presence stanzas coming out of a countryside. When there is at least one active farm on the countryside, the registry records the countryside and makes that information available upon a disco#items request.
Villein: an XMPP client that is identified by a fully-qualified JID. A villein is a software application that is executed by a resource consumer. The purpose of a villein is to communicate with farms to spawn and compute with virtual machines. A villein communicates with virtual machines to perform some type of distributed computation by leveraging remote computing resources. "Chunks" of computation submitted to a virtual machine from a villein are known as jobs. The term "villein" comes from the medival jargon where "villeins generally rented small homes, with or without land. As part of the contract with their landlord, they were expected to use some of their time to farm the lord's fields"This quote was taken from the surfdom Wikipedia entry on 06-06-2009..

In short, a resource consumer maintains a villein that communicates with a resource provider's farm in order to spawn and compute with a virtual machine that leverages the computing resources of the provider.

Given that Linked Process provides an Internet-scale, general-purpose compute cloud, there are many use cases. Before listing a collection of general use case scenarios, the following subsections will present the possible interactions that can occur in a Linked Process cloud. These interactions are specified with protocol examples. Once the specifics of the protocol are understood, the end of this section will discuss more generalized scenarios in which Linked Process can be useful.

This is the list of the XMPP stanzas (i.e. packets) that MUST be supported by a farm implementation.

<presence/>: for denoting presence status and for managing subscriptions.
<spawn_vm/>: for creating a new virtual machine.
<submit_job/>: for executing/computing/evaluating an expression in a virtual machine.
<ping_job/>: for inquiring about the status/progress/state of a job in a virtual machine.
<abort_job/>: for canceling/stopping the execution of a job in a virtual machine.
<manage_bindings/>: for getting and setting variable bindings in a virtual machine.
<terminate_vm/>: for halting/quitting/closing a virtual machine.
disco#info: for discovering the permissions, configurations, and statistics of a farm and its spawned virtual machines.

The farm specification for <presence/> is built on the specification as defined by the Instant Messaging XMPP specificationPlease refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.. What follows is a collection of guidelines regarding the use of <presence/> by a farm.

All <presence type="subscribe"/> requests SHOULD be accepted with a <presence type="subscribed"/> response. Moreover, it is RECOMMENDED that subscriptions not be bidirectional in order to reduce XMPP communication overhead. Thus, villeins can subscribe to farms, but farms do not subscribe to villeins. Finally, <presence type="unsubscribe"/> should be handled in an analogous mannerThis guideline is a SHOULD as opposed to a MUST as there may be cases where a farm instance wishes to divert from the guideline in order to handle known malicious JIDs or to ensure a private farm (or private cloud)..
The priority of a farm SHOULD be the highest priority. Thus, all stanzas sent to the bare JID should go to the farm.
The status message of a <presence/> stanza SHOULD be human readable and useful for a human to discern the current state of the farm.

There are three types of non-subscription-based <presence/> stanzas that a farm produces.

type="available": an availalbe presence denotes that the farm is active and accepting stanzas.
<show>dnd</show>: an available presence but with a "do not disturb" denotes that the farm is busy and is not accepting stanzas of type <spawn_vm/>
type="unavailable": an unavailable presence denotes that the farm is inactive and is not accepting any stanzas.

A <spawn_vm/> element is wrapped by an <iq/> element. The purpose of <spawn_vm/> is to have a farm create a new virtual machine. It is through a virtual machine that a villein is able to access the computing resources of the physical device that hosts the farm (i.e. the resource provider). A virtual machine will maintain a state throughout a villein "session" with that virtual machine. The only way to alter the state of a virtual machine is through submitting jobs and updating its variable bindingsThis is an important concept to understand. During the life of a virtual machine, the virtual machine has a state that changes as jobs are submitted and bindings are managed. In other words, a virtual machine is not a "one-job" machine..

Villein generated <iq type="get"> <spawn_vm/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_species attribute: the language of the virtual machine to be spawned (values are implementation dependent).
- farm_password attribute: the password of the farmThis is an OPTIONAL attribute. Farm passwords are useful for creating private farms in order, for example, to allow "looser" permissions with known villeins. If no password is required (e.g. a public farm), then no farm_password attribute SHOULD be provided..
Farm generated <iq type="result"> or <iq type="error"> <spawn_vm/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: a farm-internal unique identifier for the newly created virtual machine. This MUST be provided if <iq type="result"/>.
- vm_species attribute: the species of the newly created virtual machine. This MUST be provided if <iq type="result"/>.
- One of these error conditions MUST be provided if <iq type="error"/>.
  - <species_not_supported/>
  - <farm_is_busy/>
  - <malformed_packet/>
  - <internal_error/>
  - <wrong_farm_password/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

]]> ]]> ]]> 'javascr' is not a supported virtual machine species ]]>

A <submit_job/> element is wrapped by an <iq/> element. The purpose of <submit_job/> is to send code (i.e. expressions, statements, instructions) to a virtual machine for execution (i.e. evaluation, interpretation). The expression SHOULD be respective of the virtual machine's language (i.e. the virtual machine's species). If they are not, then evaluation errors SHOULD occur. The expression submitted through a <submit_job/> stanza can be short (e.g. set a variable value, get a variable value) or long (e.g. define a class/method, execute a long running body of statements). The submitted expression is called a job in Linked Process and is assigned a job_id as specified by the <iq/> id attribute value. That is, the staza id of the <submit_job/> is the job's id.

Villein generated <iq type="get"> <submit_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- <submit_job/> text body: the expression for the virtual machine to evaluate. If no text body is provided, the expression to be evaluated can be interpreted as a blank string or a null expression. The behavior of such an evaluation is up to the virtual machine implementation.
Farm generated <iq type="result"> or <iq type="error"> <submit_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- <submit_job/> text body: the result of the expression evaluated.
- One of these error conditions MUST be provided if <iq type="error"/>Note that, according to XMPP Core, it is RECOMMENDED that an <iq type="error"/> return the the query provided by the villein. In the example above, only the tag name is provided without the full body. The reason for this is that for <submit_job/>, the length of the text body of the tag is unrestricted and thus could be a very large piece of code. Thus, returning the original <submit_job/> stanza in the error response could lead to excessive communication overhead..
  - <malformed_packet/>
  - <internal_error/>
  - <evaluation_error/>
  - <permission_denied/>
  - <job_already_exists/>
  - <vm_is_busy/>
  - <vm_not_found/>
  - <job_timed_out/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

var temp=0; for(i=0; i<10; i++) { temp = temp + 1; } temp; ]]> 10 ]]>

The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <submit_job/>.

temp + 1; ]]> 11 ]]> bad_variable; ]]>

ReferenceError: "bad_variable" is not defined at line number 1

]]>

A <ping_job/> element is wrapped by an <iq/> element. The purpose of <ping_job/> is to determine the status (i.e. progress, state) of a previously submitted <submit_job/> stanza (i.e. job) that has yet to complete.

Villein generated <iq type="get"> <ping_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- job_id attribute: the job identifier (the job identifier is the stanza identifier of the respective <submit_job/>).
Farm generated <iq type="result"> or <iq type="error"> <ping_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- status attribute: the job's status. This MUST be provided if <iq type="result"/>.
  - in_progress: the job is in progress.
- job_id attribute: the job identifier for the status being reported.
- One of these error conditions MUST be provided if <iq type="error"/>.
  - <malformed_packet/>
  - <vm_not_found/>
  - <internal_error/>
  - <job_not_found/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

]]> ]]>

An <abort_job/> element is wrapped by an <iq/> element. The purpose of <abort_job/> is to cancel (i.e. quit, stop, halt) a previously submitted, yet not completed <submit_job/> stanza (i.e. job).

Villein generated <iq type="get"> <abort_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- job_id attribute: the job identifier (the job identifier is the stanza identifier of the respective <submit_job/>).
Farm generated <iq type="result"> or <iq type="error"> <abort_job/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- One of these error conditions MUST be provided if <iq type="error"/>.
  - <malformed_packet/>
  - <vm_not_found/>
  - <internal_error/>
  - <job_not_found/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

]]> ]]> ]]>

Job 'zzzz' was not found in the virtual machine.

]]>

A <manage_bindings/> element is wrapped by an <iq/> element. The purpose of <manage_bindings/> is to allow a villein to get and set variables in the variable space of a virtual machine. The definition of the "variable space" is up to the implementation of the virtual machine. In general, this is the set of all global variables for the virtual machine.

Villein generated <iq type="get"> or <iq type="set"> <manage_bindings/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- <binding/> child tag of <manage_bindings/> for <iq type="get"/>
  - name attribute: the name of the variable.
- <binding/> child tag of <manage_bindings/> for <iq type="set"/>
  - name attribute: the name of the variable.
  - value attribute: the value of the variable.
  - datatype attribute: the datatype of the variable (specified using XML schema for datatypes).
Farm generated <iq type="result"> or <iq type="error"> <manage_bindings/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- <binding/> child tag of <manage_bindings/> for <iq type="get"/>
  - name attribute: the name of the variable.
  - value attribute: the value of the variable.
- One of these error conditions MUST be provided if <iq type="error"/>.
  - <malformed_packet/>
  - <vm_not_found/>
  - <internal_error/>
  - <unknown_datatype/>
  - <invalid_value/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

]]> ]]> ]]> ]]>

After the previous <manage_bindings/> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript

var fact = name + " knows josh and peter";

will set fact to the value "marko knows josh and peter" as well as make it an accessible binding.

]]> ]]>

A useful aspect of <manage_bindings/> is that it can be used to track the state of a variable during the execution of a job. For example, suppose the following job is submitted to a JavaScript virtual machine.

var x = 1.0;
while(true) {
  x = x + 0.0001;
}

This job will continue indefinitely (or until it is timed out by the virtual machine). However, during its execution, it is possible to determine the current state of x using <manage_bindings/>. Each get-based <manage_bindings/> call should return a larger x value.

A <terminate_vm/> element is wrapped by an <iq/> element. The purpose of a <terminate_vm/> is to shutdown (i.e. quit, exit, halt) the virtual machine. Upon termination, the virtual machine will lose its state and will no longer be able to be communicated with.

Villein generated <iq type="get"> <terminate_vm/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
Farm generated <iq type="result"> or <iq type="error"> <terminate_vm/>:
- xmlns attribute: http://linkedprocess.org/2009/06/Farm#.
- vm_id attribute: the farm-internal unique identifier of the virtual machine.
- One of these error conditions MUST be provided if <iq type="error"/>.
  - <malformed_packet/>
  - <vm_not_found/>
  - <internal_error/>
  - if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <text/>. Error responses extend the requirements set forth by the Core XMPP specification.

]]> ]]>

A farm uses the XEP-0030 XMPP extension for allowing villeins to discover what features and permissions a farm and its spawned virtual machines support.

The <identity/> of a farm MUST be of category="client" and type="bot". The name attribute is up to the implementation.

<identity category="client" name="LoPFarm" type="bot"/>

The following <feature/>s MUST be supported by a farm:

<feature var="http://jabber.org/protocol/disco#info"/>
<feature var="http://linkedprocess.org/2009/06/Farm#"/>

The http://linkedprocess.org/2009/06/Farm# <feature/> denotes that the XMPP client is in fact a farm.

For presenting permissions, configurations, and statistics, a farm uses the data forms XEP-0004 XMPP extension in its disco#info response. The following list of <field/> variables (var) are presented below with their requirements specification. What is published by the farm's data form MUST be what is implemented by the farm and its spawned virtual machines. In other words, the data form MUST be consistent with the behavior of the farm and the virtual machinesWhat is provided is not an exhaustive list as there may be other permissions that are desired that can not be known apriori by the developers of this specification. For example, there may be computing resources such as hardware (e.g. video cards, FPGA components) that can have specialized requirements and parameters. Moreover, particular implementations of a Linked Process farm may have specific permissions that are not general to all implementaitons (e.g. Java-specific permissions). The data forms specification provided here can be extended to support such farm specific resources..

Field	Type	Option	Status	Label
farm_password	boolean	false	REQUIRED	Denotes whether a password is required to spawn virtual machines.
ip_address	list-single	false	RECOMMENDED	The IP address of the device hosting the farm.
vm_species	list-single	true	REQUIRED	The virtual machine species supported by the farm.
vm_time_to_live	list-single	false	REQUIRED	The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.
job_timeout	text-single	false	REQUIRED	The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.
job_queue_capacity	text-single	false	RECOMMENDED	The number of jobs which a virtual machine can hold in its queue before it rejects requests to submit additional jobs. A value of -1 means infinite.
max_concurrent_vms	text-single	false	RECOMMENDED	The number of concurrent virtual machines which the farm can support before it rejects a request to spawn a new virtual machine. A value of -1 means infinite.
farm_start_time	text-single	false	RECOMMENDED	The `xs:dateTime` at which this farm was started.
read_file	list-multi	false	RECOMMENDED	The directories/files that virtual machine's have read access to.
write_file	list-multi	false	RECOMMENDED	The directories/files that virtual machine's have write access to.
delete_file	list-multi	false	RECOMMENDED	The directories/files that virtual machine's have delete access to.
open_connection	boolean	false	RECOMMENDED	Whether a socket connection is allowed by the virtual machine.
listen_for_connection	boolean	false	RECOMMENDED	Whether a socket connection can be listened for by the virtual machines.
accept_connection	boolean	false	RECOMMENDED	Whether a socket connection can be accepted by the virtual machines.
perform_multicast	boolean	false	RECOMMENDED	Whether an IP multicast can be initiated by the virtual machines.

The previously defined interactions can be used in concert to perform some distributed computing task. A list of general use cases are presented below.

Parallel algorithm execution [consuming clock cycle resources]: parallel algorithms can be designed to exploit a Linked Process cloud. By making use of multiple physical devices for the execution of a parallel algorithm, it is possible to speedup the execution of the algorithm with respect to its serial representation. There are many algorithms of this class ranging in application areas from image processing, matrix operations, physics simulators, etc.
Distributed data processing [consuming data set resources]: with the proflic growth of online data in various repositories such as relational databases, graph databases, file repositories, etc. being able to make use of that data in ways not necessarily intended by the publishers of such data is becoming a necessary. Currently, such data is either migrated to the processing device or repeatedly queried over the Internet. With Linked Process it is possible to avoid the "over the wire" costs of migrating large amounts of data and queries by moving the code to the source of the data. In other words, with Linked Process it is possible to move the process to the data, not the data to the process.

The previous list has a collection of more specific application scenarios that are itemized below. Please note that this list is not intended to be exhaustive and provides points of inspiration for the development of more use cases for Linked Process.

Small device acceleration [consuming clock cycle resources]: with the growing use of small Internet-enabled devices such as mobile/cell phones, it is possible for such devices to make use of the computing power offered by a Linked Process cloud. Thus, while a small device may be limited in its processing power, other devices in a Linked Process cloud can support the small device's computing needs. This becomes increasingly important as cell phone cameras are being used in applications that require computationally expensive image processing algorithms.
Cell phone resources allocation [consuming hardware component resources]: Internet-enabled cell phones with computing resources such as cameras and Global Positioning Systems (GPS) make it possible to provide these resources in a Linked Process cloud. It is possible to develop villeins that locate phones with particular qualities (e.g. a particular position in space and an accessible camera) and leverage large numbers of such devices for a computation (e.g. massive imaging of an area).
Spreadable applications [consuming software API resources]: the current design paradigm in online services such as the increasingly popular "social" services is to have a centralized server that maintains all the data of its users. These services also provide various methods to make use of such data (e.g. search, recommendation, message passing). With the ability to migrate code between physical devices, it is possible to create similar services that are not centralized, but instead distributed in a more peer-to-peer manner.
Simulated remote procedure call [consuming software API resources]: Linked Process allows for lower-level control of the resources provided by a resource provider. However, with software APIs being a computing resource, it is possible for resource providers to support high-level functions/methods for manipulating resources in the way of accessible APIs/packages/libraries. In this way, RPC-based models of distributed computing can be simulated.

This is the list of the stanzas that MUST be supported by a registry.

<presence/>: for denoting presence status and for managing subscriptions.
disco#items: for discovering countrysides with active farms.
disco#info: for discovering the features of a registry.

A registry makes use of <presence/> stanzas for determining the availability of farms on a countryside. In order to monitor <presence/> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In Instant Messaging, this is handled using this sequence of <presence/> communication.

]]>

After a subscription pairing has been established, the registry will then monitor all <presence/> stanza emanating from the countryside of the subscribing XMPP client. When a registry receives a <presence type="available"/> stanza from a farm (determined through disco#info), then the registry will add the countryside (the bare JID of the farm) to its index. When the registry receives a <presence type="unavailable"/> stanza from a farm, it will only remove that farm's countryside from its index if no other active farms are available at that countryside. In short, a registry only publishes countrysides (i.e. bare JIDs), not farms (i.e. fully-qualified JIDs). However, the determinant for publishing countrysides is the availability of active farms based off the bare JID countryside.

A registry uses the XEP-0030 XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a disco#info query. The <item/> elements denote countrysides. For example, <item jid="lanl_countryside@lanl.linkedprocess.org"/> denotes that there is at least one active farm at lanl_countryside@lanl.linkedprocess.org.

]]> ]]>

A registry uses the XEP-0030 XMPP extension for allowing villeins to discover what features a registry supports.

The <identity/> of a registry MUST be of category="client" and type="bot". The name attribute is up to the implementation.

<identity category="client" name="LoPRegistry" type="bot"/>

The following <feature/>s MUST be supported by a registry:

<feature var="http://jabber.org/protocol/disco#info"/>
<feature var="http://jabber.org/protocol/disco#items"/>
<feature var="http://linkedprocess.org/2009/06/Registry#"/>

The http://linkedprocess.org/2009/06/Registry# <feature/> denotes that the XMPP client is in fact a registry.

The error codes associated with the http://linkedprocess.org/2009/06/Farm# namespace are fairly complicated as there are various states that a farm and its virtual machines can be in. The following error codes are summarized in the table below. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to Error Condition Mappings. Implementations SHOULD support both legacy and XMPP error handling.

Code	Type	Condition	Specific	Element	Purpose
400	Modify	bad-request	malformed_packet	all	The provided stanza was not properly constructed.
401	Auth	not-authorized	wrong_farm_password	spawn_vm	The supplied farm password was incorrect.
409	Cancel	conflict	internal_error	all	An error internal to the farm has occurred.
503	Cancel	service-unavailable	farm_is_busy	spawn_vm	The farm is out of resources and can not spawn a new virtual machine.
400	Modify	bad-request	species_not_supported	spawn_vm	The provided virtual machine species is not supported by the farm.
404	Cancel	item-not-found	vm_not_found	all except spawn_vm	The virtual machine id does not point to an existing virtual machine.
503	Cancel	service-unavailable	vm_is_busy	submit_job	The virtual machine has too many jobs in its queue and will not accept anymore.
400	Modify	bad-request	evaluation_error	submit_job	The supplied job expression threw an error in the virtual machine.
403	Auth	forbidden	permission_denied	submit_job	The supplied job expression violated a security permission in the virtual machine.
409	Cancel	conflict	job_already_exists	submit_job	The supplied job identifier already exists in the virtual machine.
408	Cancel	request-timed-out	job_timed_out	submit_job	The submitted job timeout and is no longer executing.
404	Cancel	item-not-found	job_not_found	ping_job and abort_job	The queried job identifier does not point to an existing job.
405	Cancel	not-allowed	job_aborted	submit_job	The submitted job was canceled.
400	Modify	bad-request	unknown_datatype	manage_bindings	The provided datatype is an unsupported datatype.
400	Modify	bad-request	invalid_value	manage_bindings	The provided value can not be converted according to the provided datatype.

This specification does not stipulate values of the XMPP <text/> element associated with the foregoing error conditions.

Linked Process can be a very dangerous protocol if implemented incorrectly. The reason for this is that foreign code is executed on devices that are unaware of the intention or purpose of the code. Thus, if farm and virtual machine implementations do not correctly respect the permissions stated by the farm (as specified in the disco#info of the farm), then it is possible for malicious or poorly written code to destroy the integrity of the executing device (i.e. the resource provider). Moreover, Linked Process devices can be utilized for nefarious purposes.

The following is a list of potentially dangerous behaviors that can be executed if a Linked Process farm and virtual machine is not implemented correctly and/or exposes permission that are too "loose."

file system corruption: if the disk I/O permissions are not implelemented correctly or not strongly specified, then the disk of the device can be compromised.
private files access: if the disco I/O permissions are not implemented correctly or not strongly specified, then potentially private information on the disk of the device can be accessed.
inappropriate access to resources: if the permissions are not implemented correctly or not strongly specified, it is possible for villeins to gain access to undesired devices such as printers, windowing toolkits, cameras, etc.
denial of service attacks: if the network I/O permissions are not implemented or strongly specified, then the device can be harvested for a denial of service (DoS) attack on other devices on the Internet.
Linked Process denial of service attacks: if the scheduler (i.e. thread operating system) of the farm is not implemented correctly, then it is possible for a farm to be overloaded by a single virtual machine rendering the farm useless to the creation of new virtual machines.

It is strongly RECOMMENDED that the implementors of a Linked Process farm and virtual machine have considerable knowledge in the area of software security and operating system engineering.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA)

The following namespaces are defined by Linked Process:

http://linkedprocess.org/2006/06/Farm#
http://linkedprocess.org/2006/06/Registry#





  
    
      The protocol documented by this schema is defined in
      Linked Process XEP-XXX: http://www.xmpp.org/extensions/xep-xxx.html
    
  

  
    
      
      
      
    
  

  
    
      
    
  

  
    
      
      
      
        
          
            
          
        
      
    
  

  
    
      
      
    
  

  
    
      
      
    
  

  
    
      
      
      
    
  

  
    
      
    
  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  
    
      
    
  


]]>

An acknowledgement of contribution must be given to Peter Neubauer (Neo Technology). Peter contributed to the testing of an implementation of the protocol that was developed in concert with this specification. Through the testing process, many issues were identified, rectified, and incorported into the protocol specification.