[Fiware-miwi] Tundra scene synchronization protocol

[Philipp Slusallek]

Hi,

Am 08.09.2013 17:05, schrieb Jonne Nauha:
> 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

Thanks for clarifying. It actually become clear to me as I was reading
the other documents that Lasse sent. The failure to be able to operate
on the data with C++ was my main concern, but I see the issue from the
scripting components.

Using KIARA however, even they could define their own components up
front and then KIARA wold generate the necessary (and optimized code) to
send those components. However, dynamically adding new attributes during
run-time would then no longer work (or be much slower). C++ might still
be able to look at it (if needed) but this would not be a fast option.

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

This optimizes for bandwidth but could make en/decoding quite a bit
slower. KIARA will allow both strategies and still generate efficient
code for both.

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

This definitely makes sense. I still think that moving the relevant
field into a single component can simplify things even more. The two are
orthogonal.

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

Sounds good. Maybe you can add a pointer to those aspect to the Wiki as
well?

>     -- Is there any notion of security?

I actually meant communication security. SSL/TLS, certificatesm ensuring
the client is talking to the right server and vice versa, etc.

But the other info is very interesting as well!


Thanks a lot and have a nice Sunday evening,

	Philipp



> 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 <http://www.meshmoon.com/> 


-- 

-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
  Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
  Prof. Dr. h.c. Hans A. Aukes

Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973, Steuernummer:  19/673/0060/3
---------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slusallek.vcf
Type: text/x-vcard
Size: 441 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130908/4439bbe8/attachment.vcf>