mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-23 08:08:53 -05:00
1042 lines
64 KiB
XML
1042 lines
64 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Linked Process Protocol</title>
|
|
<abstract>
|
|
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.
|
|
</abstract>
|
|
<legal>
|
|
<copyright>
|
|
Linked Process is copyright (c) 2009 by the Los Alamos National Laboratory of the United States Government.
|
|
</copyright>
|
|
<permissions>
|
|
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.
|
|
</permissions>
|
|
<warranty>
|
|
## 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. ##
|
|
</warranty>
|
|
<liability>
|
|
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.
|
|
</liability>
|
|
<conformance>
|
|
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 <<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
|
|
</conformance>
|
|
</legal>
|
|
<number>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0001</spec>
|
|
<spec>XEP-0004</spec>
|
|
<spec>XEP-0030</spec>
|
|
<spec>XEP-0086</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
<author>
|
|
<firstname>Marko</firstname>
|
|
<surname>Rodriguez</surname>
|
|
<email>marko@markorodriguez.com</email>
|
|
<jid>okrammarko@gmail.com</jid>
|
|
<uri>http://markorodriguez.com</uri>
|
|
</author>
|
|
<author>
|
|
<firstname>Joshua</firstname>
|
|
<surname>Shinavier</surname>
|
|
<email>josh@fortytwo.net</email>
|
|
<jid>parcour@gmail.com</jid>
|
|
<uri>http://fortytwo.net</uri>
|
|
</author>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2009-09-18</date>
|
|
<initials>psa</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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.
|
|
<ul>
|
|
<li>The term <strong>computing device</strong> 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.</li>
|
|
<li>The term <strong>computing resources</strong> 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.</li>
|
|
<li>The term <strong>compute cloud</strong> is the collection of all Linked Process enabled devices, their resources, and the Linked Process specific software components defined later in this specification.</li>
|
|
</ul>
|
|
</p>
|
|
<p>
|
|
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)<note>Nothing prevents the same device from being a resource consumer in one context and being a resource provider in another.</note>. 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).
|
|
</p>
|
|
<p>
|
|
Linked process is unlike Remote Procedure Call (RPC) and Web Service models, where the means by which resources are consumed are defined <em>apriori</em> 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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>
|
|
Linked Process was developed to address the following two distributed computing requirements: <em>Internet-scale</em> and <em>general-purpose</em>. These requirements imply yet more requirements which accompany their description below.
|
|
</p>
|
|
<ul>
|
|
<li><strong>Internet-scale</strong>: 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.</li>
|
|
<ul>
|
|
<li><strong>Decentralized</strong>: it is required that the computing resources are not necessarily centralized or controlled by any one party.</li>
|
|
<li><strong>Discoverable</strong>: it is required that resource providers be discoverable by resources consumers.</li>
|
|
<li><strong>Transient</strong>: it is required that devices coming online and offline are gracefully incoporated and removed from the cloud.</li>
|
|
</ul>
|
|
<li><strong>General-purpose</strong>: It is required that consumers be able to utilize provided resources for any desired purpose.</li>
|
|
<ul>
|
|
<li><strong>Language-agnostic</strong>: it is required that the protocol support the migration of code written in any computer language.</li>
|
|
<li><strong>Safe</strong>: it is required that the execution of consumer code be confined by permissions clearly specified by the resource provider<note>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.</note>.</li>
|
|
<li><strong>Accessible</strong>: 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.</li>
|
|
</ul>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<p>
|
|
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<note>The term <strong>entity</strong> is a generic term refering to a software component that is involved in a Linked Process cloud.</note>. The naming convention used follows a "rural" theme<note>Given the rural naming convention, the term <strong>cloud</strong> could have been substituted by the terms <strong>nation</strong> or <strong>world</strong>. However, in order to maintain some connection to the terminology of the distributed computing community, the term <strong>cloud</strong> was opted for instead the more consistent "earthly" term.</note>.
|
|
</p>
|
|
<ul>
|
|
<li><strong>Countryside</strong>: 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.</li>
|
|
|
|
<li><strong>Farm</strong>: 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 cloud<note>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.</note> 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</li>
|
|
|
|
<li><strong>Virtual machine</strong>: 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.</li>
|
|
|
|
<li><strong>Registry</strong>: 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 <tt>disco#items</tt> request.</li>
|
|
|
|
<li><strong>Villein</strong>: 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 <strong>jobs</strong>. 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"<note>This quote was taken from the <link url="http://en.wikipedia.org/wiki/Serfdom">surfdom</link> Wikipedia entry on 06-06-2009.</note>.</li>
|
|
</ul>
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<section2 topic="Farm Use Cases">
|
|
<p>
|
|
This is the list of the XMPP stanzas (i.e. packets) that MUST be supported by a farm implementation.
|
|
</p>
|
|
<ul>
|
|
<li><tt><presence/></tt>: for denoting presence status and for managing subscriptions.</li>
|
|
<li><tt><spawn_vm/></tt>: for creating a new virtual machine.</li>
|
|
<li><tt><submit_job/></tt>: for executing/computing/evaluating an expression in a virtual machine.</li>
|
|
<li><tt><ping_job/></tt>: for inquiring about the status/progress/state of a job in a virtual machine.</li>
|
|
<li><tt><abort_job/></tt>: for canceling/stopping the execution of a job in a virtual machine.</li>
|
|
<li><tt><manage_bindings/></tt>: for getting and setting variable bindings in a virtual machine.</li>
|
|
<li><tt><terminate_vm/></tt>: for halting/quitting/closing a virtual machine.</li>
|
|
<li><tt>disco#info</tt>: for discovering the permissions, configurations, and statistics of a farm and its spawned virtual machines.</li>
|
|
</ul>
|
|
|
|
<section3 topic="Rules Regarding Farm Presence">
|
|
<p>
|
|
The farm specification for <tt><presence/></tt> is built on the specification as defined by the <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link> XMPP specification<note>Please refer to the Extensible Messaging and Presence Protocol (XMPP): Instance Messaging and Presence specification.</note>. What follows is a collection of guidelines regarding the use of <tt><presence/></tt> by a farm.
|
|
</p>
|
|
<ul>
|
|
<li>All <tt><presence type="subscribe"/></tt> requests SHOULD be accepted with a <tt><presence type="subscribed"/></tt> response. Moreover, it is RECOMMENDED that subscriptions <em>not</em> be bidirectional in order to reduce XMPP communication overhead. Thus, villeins can subscribe to farms, but farms do not subscribe to villeins. Finally, <tt><presence type="unsubscribe"/></tt> should be handled in an analogous manner<note>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).</note>.</li>
|
|
<li>The priority of a farm SHOULD be the highest priority. Thus, all stanzas sent to the bare JID should go to the farm.</li>
|
|
<li>The status message of a <tt><presence/></tt> stanza SHOULD be human readable and useful for a human to discern the current state of the farm.</li>
|
|
</ul>
|
|
<p>
|
|
There are three types of non-subscription-based <tt><presence/></tt> stanzas that a farm produces.
|
|
</p>
|
|
<ul>
|
|
<li><tt>type="available"</tt>: an availalbe presence denotes that the farm is active and accepting stanzas.</li>
|
|
<li><tt><show>dnd</show></tt>: an available presence but with a "do not disturb" denotes that the farm is busy and is not accepting stanzas of type <tt><spawn_vm/></tt></li>
|
|
<li><tt>type="unavailable"</tt>: an unavailable presence denotes that the farm is inactive and is not accepting any stanzas.</li>
|
|
</ul>
|
|
</section3>
|
|
|
|
<section3 topic="Spawning a Virtual Machine">
|
|
<p>
|
|
A <tt><spawn_vm/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of <tt><spawn_vm/></tt> 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<note>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.</note>.
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> <tt><spawn_vm/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_species</tt> attribute: the language of the virtual machine to be spawned (values are implementation dependent).</li>
|
|
<li><tt>farm_password</tt> attribute: the password of the farm<note>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 <tt>farm_password</tt> attribute SHOULD be provided.</note>.</li>
|
|
</ul>
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><spawn_vm/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: a farm-internal unique identifier for the newly created virtual machine. This MUST be provided if <tt><iq type="result"/></tt>.</li>
|
|
<li><tt>vm_species</tt> attribute: the species of the newly created virtual machine. This MUST be provided if <tt><iq type="result"/></tt>.</li>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt>.</li>
|
|
<ul>
|
|
<li><tt><species_not_supported/></tt></li>
|
|
<li><tt><farm_is_busy/></tt></li>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li><tt><wrong_farm_password/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
|
|
<example caption="A successful <spawn_vm/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<example caption="An unsuccessful <spawn_vm/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
</section3>
|
|
|
|
<section3 topic="Submitting a Job to a Virtual Machine">
|
|
<p>
|
|
A <tt><submit_job/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of <tt><submit_job/></tt> 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 <tt><submit_job/></tt> 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 <strong>job</strong> in Linked Process and is assigned a <tt>job_id</tt> as specified by the <tt><iq/></tt> <tt>id</tt> attribute value. That is, the staza id of the <tt><submit_job/></tt> is the job's id.
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> <tt><submit_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt><submit_job/></tt> 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.</li>
|
|
</ul>
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><submit_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt><submit_job/></tt> text body: the result of the expression evaluated.</li>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt><note>Note that, according to XMPP Core, it is RECOMMENDED that an <tt><iq type="error"/></tt> 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 <tt><submit_job/></tt>, 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 <tt><submit_job/></tt> stanza in the error response could lead to excessive communication overhead.</note>.</li>
|
|
<ul>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li><tt><evaluation_error/></tt></li>
|
|
<li><tt><permission_denied/></tt></li>
|
|
<li><tt><job_already_exists/></tt></li>
|
|
<li><tt><vm_is_busy/></tt></li>
|
|
<li><tt><vm_not_found/></tt></li>
|
|
<li><tt><job_timed_out/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
|
|
<example caption="A successful <submit_job/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<p>
|
|
The virtual machine's state exists over the villein's session with the virtual machine. Thus, note the result of the following <tt><submit_job/></tt>.
|
|
</p>
|
|
<example caption="A successful <submit_job/> request demonstrating the consistency of a virtual machine's state between <submit_job/> requests."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]>
|
|
</example>
|
|
<example caption="An unsuccessful <submit_job/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
</section3>
|
|
|
|
<section3 topic="Determining the Status of a Virtual Machine Job">
|
|
<p>
|
|
A <tt><ping_job/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of <tt><ping_job/></tt> is to determine the status (i.e. progress, state) of a previously submitted <tt><submit_job/></tt> stanza (i.e. job) that has yet to complete.
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> <tt><ping_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt>job_id</tt> attribute: the job identifier (the job identifier is the stanza identifier of the respective <tt><submit_job/></tt>).</li>
|
|
</ul>
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><ping_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt>status</tt> attribute: the job's status. This MUST be provided if <tt><iq type="result"/></tt>.</li>
|
|
<ul>
|
|
<li><tt>in_progress</tt>: the job is in progress.</li>
|
|
</ul>
|
|
<li><tt>job_id</tt> attribute: the job identifier for the status being reported.</li>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt>.</li>
|
|
<ul>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><vm_not_found/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li><tt><job_not_found/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
<example caption="A successful <ping_job/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
|
|
</section3>
|
|
<section3 topic="Aborting a Virtual Machine Job">
|
|
<p>
|
|
An <tt><abort_job/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of <tt><abort_job/></tt> is to cancel (i.e. quit, stop, halt) a previously submitted, yet not completed <tt><submit_job/></tt> stanza (i.e. job).
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> <tt><abort_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt>job_id</tt> attribute: the job identifier (the job identifier is the stanza identifier of the respective <tt><submit_job/></tt>).</li>
|
|
</ul>
|
|
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><abort_job/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt>.</li>
|
|
<ul>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><vm_not_found/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li><tt><job_not_found/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
|
|
<example caption="A successful <abort_job/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<example caption="An unsuccessful <abort_job/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
</section3>
|
|
<section3 topic="Managing Virtual Machine Variable Bindings">
|
|
<p>
|
|
A <tt><manage_bindings/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of <tt><manage_bindings/></tt> 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.
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> or <tt><iq type="set"></tt> <tt><manage_bindings/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt></li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt><binding/></tt> child tag of <tt><manage_bindings/></tt> for <tt><iq type="get"/></tt></li>
|
|
<ul>
|
|
<li><tt>name</tt> attribute: the name of the variable.</li>
|
|
</ul>
|
|
<li><tt><binding/></tt> child tag of <tt><manage_bindings/></tt> for <tt><iq type="set"/></tt></li>
|
|
<ul>
|
|
<li><tt>name</tt> attribute: the name of the variable.</li>
|
|
<li><tt>value</tt> attribute: the value of the variable.</li>
|
|
<li><tt>datatype</tt> attribute: the datatype of the variable (specified using <link url="http://www.w3.org/TR/xmlschema-2/">XML schema for datatypes</link>).</li>
|
|
</ul>
|
|
</ul>
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><manage_bindings/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li><tt><binding/></tt> child tag of <tt><manage_bindings/></tt> for <tt><iq type="get"/></tt></li>
|
|
<ul>
|
|
<li><tt>name</tt> attribute: the name of the variable.</li>
|
|
<li><tt>value</tt> attribute: the value of the variable.</li>
|
|
</ul>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt>.</li>
|
|
<ul>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><vm_not_found/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li><tt><unknown_datatype/></tt></li>
|
|
<li><tt><invalid_value/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
<example caption="A successful <manage_bindings/> set request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<example caption="A successful <manage_bindings/> get request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<p>
|
|
After the previous <tt><manage_bindings/></tt> stanza has been processed by the virtual machine, it is possible to use the bindings in a statement. For example, in JavaScript
|
|
|
|
<code>var fact = name + " knows josh and peter";</code>
|
|
|
|
will set <tt>fact</tt> to the value "marko knows josh and peter" as well as make it an accessible binding.
|
|
</p>
|
|
<example caption="A successful <manage_bindings/> get request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
<p>
|
|
A useful aspect of <tt><manage_bindings/></tt> 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.<code>var x = 1.0;
|
|
while(true) {
|
|
x = x + 0.0001;
|
|
}</code>
|
|
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 <tt>x</tt> using <tt><manage_bindings/></tt>. Each get-based <tt><manage_bindings/></tt> call should return a larger <tt>x</tt> value.
|
|
</p>
|
|
</section3>
|
|
<section3 topic="Terminating a Virtual Machine">
|
|
<p>
|
|
A <tt><terminate_vm/></tt> element is wrapped by an <tt><iq/></tt> element. The purpose of a <tt><terminate_vm/></tt> 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.
|
|
</p>
|
|
<ul>
|
|
<li>Villein generated <tt><iq type="get"></tt> <tt><terminate_vm/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
</ul>
|
|
<li>Farm generated <tt><iq type="result"></tt> or <tt><iq type="error"></tt> <tt><terminate_vm/></tt>:</li>
|
|
<ul>
|
|
<li><tt>xmlns</tt> attribute: <tt>http://linkedprocess.org/2009/06/Farm#</tt>.</li>
|
|
<li><tt>vm_id</tt> attribute: the farm-internal unique identifier of the virtual machine.</li>
|
|
<li>One of these error conditions MUST be provided if <tt><iq type="error"/></tt>.</li>
|
|
<ul>
|
|
<li><tt><malformed_packet/></tt></li>
|
|
<li><tt><vm_not_found/></tt></li>
|
|
<li><tt><internal_error/></tt></li>
|
|
<li>if an error occurred, the farm SHOULD provide some implementation specific human-readable information detailing the error in <tt><text/></tt>. Error responses extend the requirements set forth by the <link url="http://xmpp.org/rfcs/rfc3920.html">Core</link> XMPP specification.</li>
|
|
</ul>
|
|
</ul>
|
|
</ul>
|
|
<example caption="A successful <terminate_vm/> request."><![CDATA[<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>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]></example>
|
|
</section3>
|
|
<section3 topic="Discovering Information About a Farm">
|
|
<p>
|
|
A farm uses the <link url="http://xmpp.org/extensions/xep-0030.html">XEP-0030</link> XMPP extension for allowing villeins to discover what features and permissions a farm and its spawned virtual machines support.
|
|
</p>
|
|
<p>
|
|
The <tt><identity/></tt> of a farm MUST be of <tt>category="client"</tt> and <tt>type="bot"</tt>. The <tt>name</tt> attribute is up to the implementation.
|
|
</p>
|
|
<ul>
|
|
<li><tt><identity category="client" name="LoPFarm" type="bot"/></tt></li>
|
|
</ul>
|
|
<p>
|
|
The following <tt><feature/></tt>s MUST be supported by a farm:
|
|
</p>
|
|
<ul>
|
|
<li><tt><feature var="http://jabber.org/protocol/disco#info"/></tt></li>
|
|
<li><tt><feature var="http://linkedprocess.org/2009/06/Farm#"/></tt></li>
|
|
</ul>
|
|
<p>
|
|
The <tt>http://linkedprocess.org/2009/06/Farm#</tt> <tt><feature/></tt> denotes that the XMPP client is in fact a farm.
|
|
</p>
|
|
<p>
|
|
For presenting permissions, configurations, and statistics, a farm uses the data forms <link url="http://xmpp.org/extensions/xep-0004.html">XEP-0004</link> XMPP extension in its <tt>disco#info</tt> response. The following list of <tt><field/></tt> variables (<tt>var</tt>) 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<note>What is provided is not an exhaustive list as there may be other permissions that are desired that can not be known <em>apriori</em> 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>.
|
|
</p>
|
|
<table caption='Fields of the data forms for the disco#info of a farm.'>
|
|
<tr>
|
|
<th>Field</th>
|
|
<th>Type</th>
|
|
<th>Option</th>
|
|
<th>Status</th>
|
|
<th>Label</th>
|
|
</tr>
|
|
<tr>
|
|
<td>farm_password</td>
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>REQUIRED</td>
|
|
<td>Denotes whether a password is required to spawn virtual machines.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>ip_address</td>
|
|
<td>list-single</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>The IP address of the device hosting the farm.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>vm_species</td>
|
|
<td>list-single</td>
|
|
<td>true</td>
|
|
<td>REQUIRED</td>
|
|
<td>The virtual machine species supported by the farm.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>vm_time_to_live</td>
|
|
<td>list-single</td>
|
|
<td>false</td>
|
|
<td>REQUIRED</td>
|
|
<td>The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>job_timeout</td>
|
|
<td>text-single</td>
|
|
<td>false</td>
|
|
<td>REQUIRED</td>
|
|
<td>The number of milliseconds for which a virtual machine may exist before it is terminated by the farm. A value of -1 means infinite.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>job_queue_capacity</td>
|
|
<td>text-single</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>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.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>max_concurrent_vms</td>
|
|
<td>text-single</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>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.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>farm_start_time</td>
|
|
<td>text-single</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>The <tt>xs:dateTime</tt> at which this farm was started.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>read_file</td>
|
|
<td>list-multi</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>The directories/files that virtual machine's have read access to.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>write_file</td>
|
|
<td>list-multi</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>The directories/files that virtual machine's have write access to.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>delete_file</td>
|
|
<td>list-multi</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>The directories/files that virtual machine's have delete access to.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>open_connection</td>
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>Whether a socket connection is allowed by the virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>listen_for_connection</td>
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>Whether a socket connection can be listened for by the virtual machines.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>accept_connection</td>
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>Whether a socket connection can be accepted by the virtual machines.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>perform_multicast</td>
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>RECOMMENDED</td>
|
|
<td>Whether an IP multicast can be initiated by the virtual machines.</td>
|
|
</tr>
|
|
</table>
|
|
</section3>
|
|
<section3 topic="General Farm Use Cases">
|
|
<p>
|
|
The previously defined interactions can be used in concert to perform some distributed computing task. A list of general use cases are presented below.
|
|
</p>
|
|
<ul>
|
|
<li><strong>Parallel algorithm execution</strong> [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.</li>
|
|
<li><strong>Distributed data processing</strong> [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.</li>
|
|
</ul>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<ul>
|
|
<li><strong>Small device acceleration</strong> [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.</li>
|
|
<li><strong>Cell phone resources allocation</strong> [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).</li>
|
|
<li><strong>Spreadable applications</strong> [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.</li>
|
|
<li><strong>Simulated remote procedure call</strong> [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.</li>
|
|
</ul>
|
|
</section3>
|
|
|
|
</section2>
|
|
<section2 topic="Registry Use Cases">
|
|
<p>
|
|
This is the list of the stanzas that MUST be supported by a registry.
|
|
</p>
|
|
<ul>
|
|
<li><tt><presence/></tt>: for denoting presence status and for managing subscriptions.</li>
|
|
<li><tt>disco#items</tt>: for discovering countrysides with active farms.</li>
|
|
<li><tt>disco#info</tt>: for discovering the features of a registry.</li>
|
|
</ul>
|
|
<section3 topic="Rules Regarding Registry Presence">
|
|
<p>
|
|
A registry makes use of <tt><presence/></tt> stanzas for determining the availability of farms on a countryside. In order to monitor <tt><presence/></tt> stanzas emanating from a countryside, a countryside MUST subscribe to and be subscribed from a registry. In <link url="http://xmpp.org/rfcs/rfc3921.html">Instant Messaging</link>, this is handled using this sequence of <tt><presence/></tt> communication.
|
|
</p>
|
|
<example caption="A successful subscription with a registry"><![CDATA[
|
|
<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"/>
|
|
]]>
|
|
</example>
|
|
<p>
|
|
After a subscription pairing has been established, the registry will then monitor all <tt><presence/></tt> stanza emanating from the countryside of the subscribing XMPP client. When a registry receives a <tt><presence type="available"/></tt> stanza from a farm (determined through <tt>disco#info</tt>), then the registry will add the countryside (the bare JID of the farm) to its index. When the registry receives a <tt><presence type="unavailable"/></tt> 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.
|
|
</p>
|
|
</section3>
|
|
<section3 topic="Locating Countrysides with Farms">
|
|
<p>
|
|
A registry uses the <link url="http://xmpp.org/extensions/xep-0030.html">XEP-0030</link> XMPP extension as the communication protocol for publishing farm-active countrysides. The registry's index is provided to any XMPP client performing a <tt>disco#info</tt> query. The <tt><item/></tt> elements denote countrysides. For example, <tt><item jid="lanl_countryside@lanl.linkedprocess.org"/></tt> denotes that there is at least one active farm at <tt> lanl_countryside@lanl.linkedprocess.org</tt>.
|
|
</p>
|
|
<example caption="A successful query for countrysides registered with a registry."><![CDATA[<iq id="xxxx" to="lp3@linkedprocess.org/registry"
|
|
from="lp1@linkedprocess.org/villein" type="get">
|
|
<query xmlns="http://jabber.org/protocol/disco#items"/>
|
|
</iq>
|
|
]]>
|
|
<![CDATA[<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>
|
|
]]>
|
|
</example>
|
|
</section3>
|
|
<section3 topic="Discovering Information About a Registry">
|
|
<p>
|
|
A registry uses the <link url="http://xmpp.org/extensions/xep-0030.html">XEP-0030</link> XMPP extension for allowing villeins to discover what features a registry supports.
|
|
</p>
|
|
<p>
|
|
The <tt><identity/></tt> of a registry MUST be of <tt>category="client"</tt> and <tt>type="bot"</tt>. The <tt>name</tt> attribute is up to the implementation.
|
|
</p>
|
|
<ul>
|
|
<li><tt><identity category="client" name="LoPRegistry" type="bot"/></tt></li>
|
|
</ul>
|
|
<p>
|
|
The following <tt><feature/></tt>s MUST be supported by a registry:
|
|
</p>
|
|
<ul>
|
|
<li><tt><feature var="http://jabber.org/protocol/disco#info"/></tt></li>
|
|
<li><tt><feature var="http://jabber.org/protocol/disco#items"/></tt></li>
|
|
<li><tt><feature var="http://linkedprocess.org/2009/06/Registry#"/></tt></li>
|
|
</ul>
|
|
<p>
|
|
The <tt>http://linkedprocess.org/2009/06/Registry#</tt> <tt><feature/></tt> denotes that the XMPP client is in fact a registry.
|
|
</p>
|
|
</section3>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Error Codes' anchor='errors'>
|
|
<section2 topic="Farm Error Codes">
|
|
<p>
|
|
The error codes associated with the <tt>http://linkedprocess.org/2009/06/Farm#</tt> 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 <link url="http://xmpp.org/extensions/xep-0086.html">Error Condition Mappings</link>. Implementations SHOULD support both legacy and XMPP error handling.
|
|
</p>
|
|
<table caption='Error codes for http://linkedprocess.org/2009/06/Farm# namespace.'>
|
|
<tr>
|
|
<th>Code</th>
|
|
<th>Type</th>
|
|
<th>Condition</th>
|
|
<th>Specific</th>
|
|
<th>Element</th>
|
|
<th>Purpose</th>
|
|
</tr>
|
|
<tr>
|
|
<td>400</td>
|
|
<td>Modify</td>
|
|
<td>bad-request</td>
|
|
<td>malformed_packet</td>
|
|
<td>all</td>
|
|
<td>The provided stanza was not properly constructed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>401</td>
|
|
<td>Auth</td>
|
|
<td>not-authorized</td>
|
|
<td>wrong_farm_password</td>
|
|
<td>spawn_vm</td>
|
|
<td>The supplied farm password was incorrect.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>409</td>
|
|
<td>Cancel</td>
|
|
<td>conflict</td>
|
|
<td>internal_error</td>
|
|
<td>all</td>
|
|
<td>An error internal to the farm has occurred.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>503</td>
|
|
<td>Cancel</td>
|
|
<td>service-unavailable</td>
|
|
<td>farm_is_busy</td>
|
|
<td>spawn_vm</td>
|
|
<td>The farm is out of resources and can not spawn a new virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>400</td>
|
|
<td>Modify</td>
|
|
<td>bad-request</td>
|
|
<td>species_not_supported</td>
|
|
<td>spawn_vm</td>
|
|
<td>The provided virtual machine species is not supported by the farm.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>404</td>
|
|
<td>Cancel</td>
|
|
<td>item-not-found</td>
|
|
<td>vm_not_found</td>
|
|
<td>all except spawn_vm</td>
|
|
<td>The virtual machine id does not point to an existing virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>503</td>
|
|
<td>Cancel</td>
|
|
<td>service-unavailable</td>
|
|
<td>vm_is_busy</td>
|
|
<td>submit_job</td>
|
|
<td>The virtual machine has too many jobs in its queue and will not accept anymore.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>400</td>
|
|
<td>Modify</td>
|
|
<td>bad-request</td>
|
|
<td>evaluation_error</td>
|
|
<td>submit_job</td>
|
|
<td>The supplied job expression threw an error in the virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>403</td>
|
|
<td>Auth</td>
|
|
<td>forbidden</td>
|
|
<td>permission_denied</td>
|
|
<td>submit_job</td>
|
|
<td>The supplied job expression violated a security permission in the virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>409</td>
|
|
<td>Cancel</td>
|
|
<td>conflict</td>
|
|
<td>job_already_exists</td>
|
|
<td>submit_job</td>
|
|
<td>The supplied job identifier already exists in the virtual machine.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>408</td>
|
|
<td>Cancel</td>
|
|
<td>request-timed-out</td>
|
|
<td>job_timed_out</td>
|
|
<td>submit_job</td>
|
|
<td>The submitted job timeout and is no longer executing.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>404</td>
|
|
<td>Cancel</td>
|
|
<td>item-not-found</td>
|
|
<td>job_not_found</td>
|
|
<td>ping_job and abort_job</td>
|
|
<td>The queried job identifier does not point to an existing job.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>405</td>
|
|
<td>Cancel</td>
|
|
<td>not-allowed</td>
|
|
<td>job_aborted</td>
|
|
<td>submit_job</td>
|
|
<td>The submitted job was canceled.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>400</td>
|
|
<td>Modify</td>
|
|
<td>bad-request</td>
|
|
<td>unknown_datatype</td>
|
|
<td>manage_bindings</td>
|
|
<td>The provided datatype is an unsupported datatype.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>400</td>
|
|
<td>Modify</td>
|
|
<td>bad-request</td>
|
|
<td>invalid_value</td>
|
|
<td>manage_bindings</td>
|
|
<td>The provided value can not be converted according to the provided datatype.</td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
This specification does not stipulate values of the XMPP <tt><text/></tt> element associated with the foregoing error conditions.
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
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 <tt>disco#info</tt> 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.
|
|
</p>
|
|
<p>
|
|
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."
|
|
</p>
|
|
<ul>
|
|
<li><strong>file system corruption</strong>: if the disk I/O permissions are not implelemented correctly or not strongly specified, then the disk of the device can be compromised.</li>
|
|
<li><strong>private files access</strong>: 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.</li>
|
|
<li><strong>inappropriate access to resources</strong>: 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.</li>
|
|
<li><strong>denial of service attacks</strong>: 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.</li>
|
|
<li><strong>Linked Process denial of service attacks</strong>: 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.</li>
|
|
</ul>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>
|
|
This document requires no interaction with the <link url="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</link>
|
|
</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
The following namespaces are defined by Linked Process:
|
|
<ul>
|
|
<li><tt>http://linkedprocess.org/2006/06/Farm#</tt></li>
|
|
<li><tt>http://linkedprocess.org/2006/06/Registry#</tt></li>
|
|
</ul>
|
|
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<code><![CDATA[<?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>
|
|
]]>
|
|
</code>
|
|
</section1>
|
|
<section1 topic="Acknowledgements" anchor='acknowledge'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
</xep>
|