%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.

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.

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..

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."

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:

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.