Live Entity State Stream (LESS) protocol descriptionForterra Systemsjwatte@gmail.comVirtual WorldsInteroperabilityMMOXLESSEntity StateState StreamProperty Replication
Virtual worlds, typically implemented as multi-user shared simulations, are
becoming increasingly used for serious work in addition to the traditional
uses of research and entertainment. Whereas previous distributed simulation
protocols have been designed with narrow, time-definite scope, the LESS
(Live Entity State Stream) protocol is designed to allow open-ended join
and leave for a multitude of simulation peers. The LESS protocol specifies
how peers of a simulation collaborate and share state to achieve a mutually
agreed "collective hallucination," leading to a user-perceivable shared
state of a simulated worlds.This protocol (the LESS protocol) describes presenting virtual world object
properties between virtual world peers (typically, servers of virtual world
instances). It allows peers to introduce the types of objects that they will
provide, and allows the responding peers to decide what types, and what
properties within those types, they actually understand and are interested in.
This protocol is part of a suite of protocols that together make up an
advanced virtual world interoperability standard; when all the protocols are
implemented by two or more separate virtual world systems, those systems can
interoperate at a high level, and provide a congruent shared experience to
participants from all the participating world implementations and peer hosts.
Additional use cases include traditional data loggers, a standardized set of
analysis tools, and others.
The basic model is that individual objects are simulated on a host that has
affinity for that object, and a certain set
of typically well-known properties (identified by id in LESS, and by well-
known name mapping to id in schema) are presented to observing peers. Those
properties are intended to provide a reasonable level of detail of presentation
for the object in question as it updates itself, but are not intended to
provide a perfect replica of the internal workings of the object. Thus, only
properties that are of interest to presentation (to users or other simulators),
or user interaction are intended to be included in the schema and data stream.
Because multiple hosts participate in the shared simulation, it is expected
that each host simulates some number of objects, presenting them to the other
host peers, while simultaneously receiving presentations of the objects
simulated on those peers. This makes a typical session using LESS bi-directional.
When objects simulated on one host interact with objects simulated on another
host, interactions defined in object schema are forwarded from the host detecting
the interaction to the host simulating the interactee. Through means outside the
scope of this protocol, the servers agree on the basic environment of the
simulation, including properties like gravity, up and North vectors, center of
coordinate reference frame if referenced to some external frame (such as WGS-84)
and static, immutable terrain geometry.
The reason for this new protocol, as opposed to various existing protocols such
as Sun-RPC, SOAP or SNMP is that virtual world objects update their properties
at typically a much higher rate of change than other kind of objects, and the
timing of those updates is important. Additionally, efficiency of encoding is
fairly important, leading to an implicit-type system that puts type description
out of line with the data update stream. The motivation for this is similar to
the motivation to use separately negotiated binary codecs for VoIP traffic or
streaming video traffic.
The model of interoperability as viewing the presentation of simulated objects
through simulation host peer connections was carefully chosen to allow the greatest
amount of interoperability possible while requiring the least amount of re-work
within existing virtual world implementations. Server-side peering to construct
a single, shared space opens up many exciting applications, that alternative
approaches to interoperability, such as a forced client/server protocol, or
a forced object execution model, would not enable. Additionally, it is expected
that the work necessary to implement LESS in existing virtual worlds is less than
that required to achieve similar interoperability through other means. A model
with the same justification, but a more anachronistic implementation, has been used
successfully within the Department of Defense for a long time (IEEE 1278; Distributed
Interactive Simulation). Meanwhile, a model that requires all participants to share
a given execution model, (like IEEE 1516; the High-Lefel Architecture) or a common
interaction description and client protocol (like VRML; Virtual Reality Mark-up
Language and its successor X3D) has not had the same success in enabling broad
interoperability across different vendor technologies.
A connection is established through means outside the scope of this protocol.
The connection includes each peer referencing a schema for the connection
(which is separate from a schema for entities and types). That schema describes
some properties about the protocol implementation (such as what properties are
allowed in the connection control messages). Authentication is also assumed to
take place during the connection set-up, before the LESS protocol is in effect.
One possible implementation is to use HTTP Upgrade: to switch from HTTP/HTTPS
to the LESS protocol.
Live entity state updates are streamed through a sequence of packets. Packets
are the physical grouping mechanism for transmission over a network or other
medium. A packet contains zero or more messages. Each message is assumed to
take effect at the timestamp defined in the packet header. Timestamps are
integral representations of time at the source end, and are relative to a clock
that only the source end knows. The duration of a single quantum of the time
stamp is approximately described in the schema for the connection.
The physical serialization of data types (ints, floats, strings and binary) is
described in addition to the logical description of how the data is organized.
The logical description assumes the use of object type schemas, as described in
the LODS (Live Object Description Schema) document. The schema for the type of
an object must be introduced into the state stream, and the receiving peer must
subscribe to properties of that type, before objects (entities) of that type
can be introduced over the wire. Also note that the name spaces and schema
spaces are not generally the same in both directions -- the connection is really
two separate connections shared over a bi-directional stream. Object id "123"
may mean something totally different when sent from peer A to peer B, as opposed
to when sent from peer B to peer A. To further confuse the matter, each message
has an implicit direction, which determines which set of identities and schemas
is used. For example, "update entity" means that properties on the source system
changed, and thus the object id references objects from the source system.
"tweak entity" messages are requests from the source to change the state of the
destination system, so the object id references objects on the destination system.
Because transport may be TCP or UDP, some ordering rules need to be enforced:
Property updates are defined to not be ordered. If a property update goes
out in a packet that is dropped, but the sending side has since sent a new
update for that same property, the old property set will not be part of the
re-send of the dropped packet. Simliarly, properties know which packet last
set them, and a received older packet with a property set will not have any
new effect on the property in question.
Meanwhile, method calls are ordered per entity. A method call may not be
effected while there are outstanding dropped, not re-sent messages in the
direciton of the pending method call message. Method calls are also effected
in the order they are sent in a packet. A corollary is that any packet
sequence number must be re-sent if dropped over a lossy connection, even if
such re-send results in a packet with no messages, to avoid later interactions
to be un-queued and effected.
How to handle three or more peers is not defined by this protocol. The connection
negotiation may tell each connecting peer about all other peers it knows about,
and only send state updates for entities that it is the master for, or the
negotiation may include a forwarding arrangement, where one end takes it opon
itself to forward entity data for some other number of peers. For that to work,
the forwarding end needs to re-number entities that come from other systems as part
of this protocol, which means that the forwarding system has to understand all the
data types that include object ids. Hence, trying to "escape" object id into binary
blobs in the protocol is not recommended.
(simplified BNF form, alternatives on separate lines)Serialization of base data types are as follows (C++-like pseudo-code):
Type codes (serialized as INTEGER). Some types have variable-length encoding
of their data; other types have an implicit (FLOAT32) or explicit (FIXED-BINARY)
length encoding.
When using UDP, the peer should send packets in sequence order, starting at a
sequence number described in the connection negotiation. Sequence numbers
increase by 1 for each packet sent, and wrap over. The receiving peer should
in turn send the latest received sequence number as ack-last-sequence-number
(with the initial value being one less than the negotiated first sequence number
in that direction). The ack-previous-bitmask is constructued such that, to send
an ack for the packet with the sequence number one before the last received
packet, the lowest bit is set. For the sequence number before that, the second
lowest bit is set. Repeat, up to 64 bits' worth of acknowledgement. This means
that the maximum outstanding window size is 64 packets. With a simulation rate
of 30 Hz, this means over two seconds of window size, which should cover any
moderately interactive scenario. If you want to support higher latency
connections without running out of bits in the 64-packet oustanding window, just
pack more into each packet, and send at a lower rate.
The UDP peer can stop putting in ack bits when it receives an ack from the other
end for some packet that it knows that the packet in question was acked in. Also
see the discussion on which bits of data to include in a packet re-send above.
Finally, there is no risk of treating a much delayed packet with the same
sequence number as the current packet as an accidentally correct packet, because
the timestamp in the header must be monotonically increasing.
This protocol intends to enable interoperability across different hosts
using different underlying virtual world technologies. Additionally, trust of
interoperating hosts is established using means external to this protocol. Thus,
a parser for the protocol should be conservative in range and value checking,
and it is recommended that a session is terminated (using means outside this
protocol) if a framing error or logical error is discovered. For example, a
remote node may attempt to introduce an object of a type for which the schema
has not been introduced, or may attempt to present a property that has not been
subscribed. A remote node may also have implementation defects that do not properly
follow the marshaling rules for data encoding. Any such deficiency should be
detected, and lead to immediate disconnection of the remote connection.
Additionally, the simulation consistency of each world host is the responsibility
of that host. Whether a given interaction, method call or property tweak is
allowed at a particular point in time must be verified by the receiving host.
By contrast to logical or framing errors, such permission errors may be caused by
user interface shortcomings, timing/race conditions, etc, and thus should not
generally result in a dropped connection, but instead a failure result in the
cases where results are reported (such as method calls).
A minimal protection against replay, out-of-order and source-spoofing attacks is
provided through the 64-bit MAC checksum preceding each packet. If the session is
initially established through secure means (such as HTTPS), and a hard-to-guess
MAC key is used to generate this checksum, an open transmission of packets over
UDP will be moderately hard to spoof using man-in-the-middle attacks or packet
alteration. However, if full encryption-grade security is required, the LESS
protocol should be used over a fully trusted channel, such as HTTPS with a high-
grade cypher and a public-key infrastructure based host trust model.
This documents does not require any IANA action.This version supersedes the document draft-jwatte-less-protocol-00.This version adds a Security Considerations section; clarifies the underlying
interoperability model; fixes some spelling errors and clarifies the use of the
MAC signature.Distributed Interactive SimulationIEEEThe High-Level ArchitectureIEEESession Vocabulary Schema Example (work in progress)J. WatteObject Type Schema Example (work in progress)J. Watte