lbsa71.net Just another WordPress weblog

On Multi-protocol

From the Not-Invented-Here Dept. 

With the recent breakthroughs in OpenSim with (theoretically) supporting multiple protocols, the question of 'How do you transfer Object of protocol X over protocol Y' and 'how do you change SecondLife(tm) prims into MXP objects and vice versa?

I got a revelation the other day that "Maybe you don't".

 One of the problems with any viewer approach is that any multi-protocol viewer has to support a multitude of protocols to be interesting. Very much a discussion like the one on video streaming and video streaming clients.

So, I propose the following;

On the server side, all objects are stored natively; Second Life compatible Objects are stored as that, X3D objects as X3D objects, and MXP objects as MXP objects.

They collaborate on the server by exposing the same set of behavioural functions (Exposing meshes for the Physics engine, and functions to add, move and change some basic set of attributes) 

All protocols are implemented as "codecs", on the server side they will very much look like OpenSim 'modules'; these codecs

a) set up protocol-specific endpoints for native clients

b) register factories to create protocol-specific instances of core objects

c) register abstracted endpoints for multiplexed transfer over what I chose to call the "Real Time Scene Transfer Protocol"

On the viewer side, each protocol is also implemented as a 'codec'; here, the codec is responsible for implementing the transformation of protocol-specific stream data into scene changes.

Now, when a client connects to a Scene, it has the choice of connecting to a native endpoint, or to the RTSTP Endpoint

If it connects to the native endpoint, it will use only that codec, which means all scene changes will go thru that protocol, and the server codec will do its best to transform content from one protocol standard to another, optionally by chaining other server codecs.

But; if it connects to the RTSTP Endpoint, it will be served a stream that is a multiplexed interleave of the output of the different protocol payloads.

If a new object should be created, it's ether going to be recieved as an SL UDP ObjectAdd Packet payload or thru an MXP Object add - depending on what type of object is added on the server.

The Stream Demultiplexer then splits the packets and sens them to the according codec, which is then responsible for adding it to the viewers local scenegraph for rendering.

One central point is that the native endpoints should probably implement the same interfaces as the multiplexed payload endpoint, so an SL EndPoint should be split into the SL UDP Transport layer and the SL Packet layer, where the native endpoint would use one, and the RTSTP multiplexer the other.

The control stream, ie, the information of user intentions, like keyboard presses and avatar navigation, can (probably?) be thought of either being multiplexed into the various protocol tunnels, or as a separate 'control pipe' funnel.

Of course, all this is very half-baked, and I'm definitively not the man to start drawing up formal proposals. I just realized I had a solution for what I foresee as a very real problem in a multi-protocol multi-standard 3D client-server model. In essence, you need a network transfer, a session, an interleaved stream and the different content streams

So, anybody has good already-existing protocols to handle this? SIP or RTSP to negotiate EndPoints configuration? OGG or Matroska for stream interleaving?

Best Regards,

Stefan Andersson aka lbsa71