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) [1]. 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 protocol [3]. The naming convention used follows a "rural" theme [4].
disco#items request.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 specification [7]. What follows is a collection of guidelines regarding the use of <presence/> by a farm.
<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 manner [8].<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 bindings [9].
<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 farm [10].<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"/>.<iq type="error"/>.
<species_not_supported/><farm_is_busy/><malformed_packet/><internal_error/><wrong_farm_password/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/villein" to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascript"/> </iq> <iq from="lp2@linkedprocess.org/farm" to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> <spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" vm_species="javascript"/> </iq>
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_species="javascr"/>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
<spawn_vm xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<error code="503" type="cancel">
<service_unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<species_not_supported xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
'javascr' is not a supported virtual machine species
</text>
</error>
</iq>
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.
<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.<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.<iq type="error"/> [11].
<malformed_packet/><internal_error/><evaluation_error/><permission_denied/><job_already_exists/><vm_is_busy/><vm_not_found/><job_timed_out/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="xxxx">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
var temp=0;
for(i=0; i<10; i++) {
temp = temp + 1;
}
temp;
</submit_job>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
10
<submit_job/>
</iq>
The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <submit_job/>.
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
temp + 1;
</submit_job>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm# vm_id="62F4E464">
11
<submit_job/>
</iq>
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="zzzz">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
bad_variable;
</submit_job>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="error" id="zzzz">
<submit_job xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<error code="400" type="modify">
<bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<evaluation_error xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
ReferenceError: "bad_variable" is not defined at line number 1
</text>
</error>
</iq>
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.
<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/>).<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.<iq type="error"/>.
<malformed_packet/><vm_not_found/><internal_error/><job_not_found/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/villein" to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/> </iq> <iq from="lp2@linkedprocess.org/farm" to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> <ping_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" status="in_progress"/> </iq>
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).
<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/>).<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.<iq type="error"/>.
<malformed_packet/><vm_not_found/><internal_error/><job_not_found/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/villein" to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="yyyy"/> </iq> <iq from="lp2@linkedprocess.org/farm" to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> <abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> </iq>
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464" job_id="zzzz"/>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="error" id="yyyy">
<abort_job xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<error code="404" type="cancel">
<item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
<job_not_found xmlns="http://linkedprocess.org/2009/06/Farm#"/>
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">
Job 'zzzz' was not found in the virtual machine.
</text>
</error>
</iq>
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.
<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).<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.<iq type="error"/>.
<malformed_packet/><vm_not_found/><internal_error/><unknown_datatype/><invalid_value/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="set" id="xxxx">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/>
<binding name="name" value="marko" datatype="http://www.w3.org/2001/XMLSchema#string"/>
</manage_bindings>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="xxxx">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/>
</iq>
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="yyyy">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age"/>
<binding name="name"/>
</manage_bindings>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="yyyy">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="age" value="29" datatype="http://www.w3.org/2001/XMLSchema#integer"/>
<binding name="name" value="marko" datatype="http://www.w3.org/2001/XMLSchema#string"/>
</manage_bindings>
</iq>
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.
<iq from="lp1@linkedprocess.org/villein"
to="lp2@linkedprocess.org/farm" type="get" id="zzzz">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="fact"/>
</manage_bindings>
</iq>
<iq from="lp2@linkedprocess.org/farm"
to="lp1@linkedprocess.org/villein" type="result" id="zzzz">
<manage_bindings xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464">
<binding name="fact" value="marko knows josh and peter"
datatype="http://www.w3.org/2001/XMLSchema#string"/>
</manage_bindings>
</iq>
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.
<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.<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.<iq type="error"/>.
<malformed_packet/><vm_not_found/><internal_error/><text/>. Error responses extend the requirements set forth by the Core XMPP specification.<iq from="lp1@linkedprocess.org/LoPVillein/EFGH" to="lp2@linkedprocess.org/farm" type="get" id="xxxx"> <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> </iq> <iq from="lp2@linkedprocess.org/farm" to="lp1@linkedprocess.org/villein" type="result" id="xxxx"> <terminate_vm xmlns="http://linkedprocess.org/2009/06/Farm#" vm_id="62F4E464"/> </iq>
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 machines [12].
| 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.
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.
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.
<presence from="lp2@linkedprocess.org/farm" to="lp3@linkedprocess.org/registry" type="subscribe"/> <presence to="lp2@linkedprocess.org/farm" from="lp3@linkedprocess.org/registry" type="subscribed"/> <presence to="lp2@linkedprocess.org/farm" from="lp3@linkedprocess.org/registry" type="subscribe"/> <presence from="lp2@linkedprocess.org/farm" to="lp3@linkedprocess.org/registry" type="subscribed"/>
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.
<iq id="xxxx" to="lp3@linkedprocess.org/registry"
from="lp1@linkedprocess.org/villein" type="get">
<query xmlns="http://jabber.org/protocol/disco#items"/>
</iq>
<iq id="xxxx" from="lp3@linkedprocess.org/registry"
to="lp1@linkedprocess.org/villein" type="result">
<query xmlns="http://jabber.org/protocol/disco#items">
<item jid="lanl_countryside@lanl.linkedprocess.org"/>
<item jid="fortytwo_countryside@fortytwo.linkedprocess.org"/>
<item jid="sweden_countryside@fortytwo.linkedprocess.org"/>
</query>
</iq>
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:
http://linkedprocess.org/2006/06/Farm#http://linkedprocess.org/2006/06/Registry#<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://linkedprocess.org/2006/06/Farm#'
xmlns='http://linkedprocess.org/2006/06/Farm#'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
Linked Process XEP-XXX: http://www.xmpp.org/extensions/xep-xxx.html
</xs:documentation>
</xs:annotation>
<xs:element name='spawn_vm'>
<xs:complexType>
<xs:attribute name='vm_species' type='xs:string' use='required'/>
<xs:attribute name='farm_password' type='xs:string' use='optional'/>
<xs:attribute name='vm_id' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='submit_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
</xs:complexType>
</xs:element>
<xs:element name='ping_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:attribute name='job_id' type='xs:string' use='optional'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='in_progress'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name='abort_job'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:attribute name='job_id' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='manage_bindings'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
<xs:element ref='binding'/>
</xs:complexType>
</xs:element>
<xs:element name='binding'>
<xs:complexType>
<xs:attribute name='name' type='xs:string' use='required'/>
<xs:attribute name='value' type='xs:string' use='optional'/>
<xs:attribute name='datatype' type='xs:simpleType' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='terminate_vm'>
<xs:complexType>
<xs:attribute name='vm_id' type='xs:string' use='required'/>
</xs:complexType>
</xs:element>
<xs:element name='malformed_packet' type='empty'/>
<xs:element name='wrong_farm_password' type='empty'/>
<xs:element name='internal_error' type='empty'/>
<xs:element name='farm_is_busy' type='empty'/>
<xs:element name='species_not_supported' type='empty'/>
<xs:element name='vm_not_found' type='empty'/>
<xs:element name='vm_is_busy' type='empty'/>
<xs:element name='evaluation_error' type='empty'/>
<xs:element name='permission_denied' type='empty'/>
<xs:element name='job_already_exists' type='empty'/>
<xs:element name='job_timed_out' type='empty'/>
<xs:element name='job_not_found' type='empty'/>
<xs:element name='job_aborted' type='empty'/>
<xs:element name='unknown_datatype' type='empty'/>
<xs:element name='invalid_value' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
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.
This document in other formats: XML PDF
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).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. Nothing prevents the same device from being a resource consumer in one context and being a resource provider in another.
2. There 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.
3. The term entity is a generic term refering to a software component that is involved in a Linked Process cloud.
4. Given 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.
5. Note 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.
6. This quote was taken from the surfdom Wikipedia entry on 06-06-2009.
7. Please refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.
8. This 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).
9. This 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.
10. This 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.
11. 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.
12. What 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.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
First draft.
@report{rodriguez2009xepxxxx,
title = {Linked Process Protocol},
author = {Rodriguez, Marko and Shinavier, Joshua},
type = {XEP},
number = {xxxx},
version = {0.0.1},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-xxxx.html},
date = {2009-09-18/2009-09-18},
}END