[Fiware-miwi] Tundra scene synchronization protocol

[Jonne Nauha]

On Sun, Sep 8, 2013 at 9:21 AM, Philipp Slusallek <Philipp.Slusallek at dfki.de
> wrote:

> Hi Lasse, all,
>
> Thanks you very much. Some comments and questions from my side (adding
> Dmitri in CC, who is our main KIARA person):
>
> -- From the document:
> > The sync protocol supports creating and removing attributes in
> > components on the fly, but for most components such as EC_Mesh or
> > EC_Placeable, the set of attributes is fixed.
>
> Are you actually making use of adding attributes at runtime? I can
> easily see that some attributes may be optional. But what would be a
> case where attributes get added to a compoenent. How would a remote node
> make use of this info, if it does not know about the attribute.
>

Currently all components except EC_DynamicComponent's structure is static
and known/locked down during build time. You cannot add attributes to any
other component during runtime than EC_DynamicComponent. This could in
theory be supported for any component, but as the C++ logic operates on the
build time knowledge of attributes the logic code could not do anything
sensible with these runtime attributes. EC_DynamicComponent is mostly
useful for scripts that can write custom handling logic for the apps custom
attributes that it wants to synchronize over the network.

For EC_DynamicComponent when a new attributes are added on either the
client or server side during runtime, a "CreateAttributes" message is sent
and replicated to everyone. This will also send the initial value of the
new attribute. After this if the value is changed the normal
"EditAttributes" is sent. If a attribute is removed during runtime the
"RemoveAttributes" message it sent.

A remote node (essentially a application script running on the server
and/or client) can detect new attributes and react to changes by hooking to
the signals in IComponent
http://doc.meshmoon.com/doxygen/class_i_component.html#signals


>
> In KIARA we try to allow strong optimization of the communication.
> Optional data is easily dealt with here (just a flag) but adding random
> new data, would defeat most optimizations. Its currently not planned to
> be supported. So I would like to understand, how its is being used and
> what alternatives might be there for these usecases (I would like not to
> give up optimization).


> Regarding the encoding, as I mentioned, this is not fixed in KIARA. The
> app describes its data structures (such as in Jonne's component
> document) and KIARA would negotiate/choose a proper encoding/protocol
> when establishing the connection (which allows us to optimize depending
> on the clients, network, and other conditions at run time). This would
> include possibly choosing a smaller network representation for smaller
> int values.
>

The protocol tries to do its best sending a little bytes as it can. This is
the VLE encoding mentioned in Lasses doc page. So in practice if the an
Entity ID in the message is 5, it will be sent as u8 instead of u32.

The details on the VLE encoding can be found from
http://clb.demon.fi/knet/_immediate_mode_serialization.html. This is
already implemented in the current Web Tundra prototype by me, so the
bit-fiddling is not a problem :)

As the bulk of Tundras network messages in an usual scene are moving
objects there is a special "RigidBodyUpdateMessage" that is not currently
on the wiki page, but is referenced by Lasse here
https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/RealXtend_Tundra_protocol#Optimizations.
Using this message reduces the bandwidth costs a lot in most cases, eg if
you move pos.x in EC_Placeable, the generic sync would send the whole
transform attribute (9x4bytes), but this is where the specialized message
kicks in an only 4 bytes is sent.


> -- It seems there needs to be some encoding also for the commands, as
> well as things like authentification and such?
>

The protocol has other messages in addition to the Scene synchronization
messages. LoginMessage sent from the client to the server and
LoginReplyMessage that is a reply for this message.

The LoginMessage is, again a generic message, which is just a set of login
properties the client wants to send to the server. This data can be
anything from only "username" to "username" + "password" + "authtoken", you
name it. All these login properties persist in the servers memory for the
whole time this client is logged in, and applications have full access to
these login properties. Applications (scripts or custom C++ plugins) can
act on the login properties and if sees fit reject the login attempt.

This login message is for example used in Meshmoon to validate a
authentication token (our client puts this token to the login properties
when used logs in to a scene) which gets validated by the Meshmoon server
side logic from our backend. So essentially the login/authentication step
can be fully customized by the application using Tundra. By default Tundra
SDK will let anyone in with any login properties, again either C++ logic or
server side script needs to implement the auth/login model of the scene. It
can range from simple username/password checks to more elaborate backend
validations against a user database etc.


>
> -- Is there any notion of security?
>

Yes, again this is very generic. The Tundra SDK does not decide what
security model you have. It provides signals to application logic (C++ or
script) to tell it if a scene change should be allowed. This has proven to
be enough in Meshmoon as we use it to determine who can make client side
scene changes. If the Meshmoon user has "basic" permission on the scene we
will reject any changes it tries to do to the scene model on the client
side. These users can still interact with the scene via the scripts in that
scene, whatever the apps there might be.

You can send custom messages via EntityActions (not yet documented on the
wiki). Basically its a way for the client to send messages with custom data
variables and the server side logic can act on it. With this mechanism you
can move the scene manipulation to the server side and thus the change is
allowed also for "basic" users.

The change requests can be catched in server side app logic from
http://doc.meshmoon.com/doxygen/class_scene_sync_state.html#signals. At
some point we will need to extend this to provide information what
component and attribute the change was targeted to. Currently it will tell
what entity the client tried to manipulate.


>
>
> Best,
>
>         Philipp
>

Lasse: Please step in if I made an factual errors :)

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.
www.meshmoon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130908/e3eef218/attachment.html>