[Fiware-miwi] Tundra scene synchronization protocol

[Jonne Nauha]

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

Yeah this can be the case. We haven't ran any profiling on the performance
of the VLE decoding or the websocket binary frame parsing in general on the
javascript side. We will certainly need to do that going forward. On the
server C++ this is a non-issue, at least under the usual world scale we are
operating on.


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

Strictly from a design standpoint I think our intent is that EC_Placeable
that is responsible for 3D scene nodes should not (need to) know about
physics/velocities and vice versa for EC_RigidBody. Usually our components
have a very specific task/feature they add to the entity. How I see it the
RigidBodyUpdateMessage consolidates both these components into a single
efficient network message about the changes in both. I see how this might
be confusing for someone who is implementing the protocol on a client, we
can certain think about it a little more.


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

I've added the login and loginreply messages to the wiki page. Also added
the message ID for each.


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

Ah sorry, I misunderstood. No afaik we don't havea any security on that
level. It would probably be up to the kNet implementation to provide it, if
it already does we are not using afaik using it.


>
>
> Thanks a lot and have a nice Sunday evening,
>
>         Philipp



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/a84aed10/attachment.html>