RFC: A reusable abstraction for multiple VW protocols

[Ryan McDougall]

An early design goal of Naali has always been that it would be multiprotocol.

Firefox doesn't depend on the server implementation, and neither
should we. Unfortunately however, we don't have HTTP to insulate us,
so we are forced to allow protocol specific elements into our code
base.

The question is what attractions can we use in order to keep as much
of our code base as possible nonspecific?

For us this question is now practical, as we are now implementing
three grid level protocols (OpenSim, Cable Beach/OpenID, and reX
Legacy), and one real-time streaming protocol (reX-modified SL UDP).

The first big distinction we make is between world Session and world
Streaming protocols.

A session protocol consists of a series of transactions in order to
set up an authorized, real-time, stream between client and server. A
stream protocol consists of a series of real-time messages used to
replicate state and events between client and server.

A session manager is handed a set of credentials in an address of a
trust the main authority, who negotiates entrance of the credentials
into the trust authority, negotiates a shared set of capabilities, and
request initiation of matching stream endpoints.

We stream and points established, a translation module includes
internal viewer events as real-time messages, and pumps them upstream.

In support of this abstraction, we will implement an RPC manager, that
will handle both XML RPC and REST-based RPC, and a data-driven UDP
encoder.

This should be enough to suit our current needs, but you believe that
that's enough to support your individual protocols as well? Do you see
any holes? Am I missing anything?

Let me know what you think.

Cheers,

[Alon Zakai]

If Naali could be truly multiprotocol, that would be an excellent result.
 

In support of this abstraction, we will implement an RPC manager, that
will handle both XML RPC and REST-based RPC, and a data-driven UDP
encoder.

What do you mean by 'data-driven UDP'?

One suggestion I can make is to check for ease of use with ENet (an MIT-licensed hi-speed UDP-based networking library, used by a lot of gaming projects, including mine). In other words, if it's easy to use ENet with Naali, that would be a great sign of multiprotocol potential.

Of course that is just the very low-level stuff, the real challenges are supporting the higher-level functionalities of multiple protocols (different updates/entities/worlds, etc.).

- kripken

[Daniel Horn]

There are future plans to support ENET as a low level protocol in
sirikata as well due to the fact that it is a good implementation of the
portions of MIT's structured stream protocol that we use in our current
Stream abstraction

[Ryan McDougall]

On Mon, Sep 28, 2009 at 4:21 PM, Alon Zakai <al...@syntensity.com> wrote:
> If Naali could be truly multiprotocol, that would be an excellent result.
>
>
>> In support of this abstraction, we will implement an RPC manager, that
>> will handle both XML RPC and REST-based RPC, and a data-driven UDP
>> encoder.
>>
>
> What do you mean by 'data-driven UDP'?

That what shows up on UDP is driven by a text file as opposed to
compiled C++ logic.

In specific, we use SL's message_template.msg. This could also mean
protocol buffers or other similar ideas.

>
> One suggestion I can make is to check for ease of use with ENet (an
> MIT-licensed hi-speed UDP-based networking library, used by a lot of gaming
> projects, including mine). In other words, if it's easy to use ENet with
> Naali, that would be a great sign of multiprotocol potential.
>
> Of course that is just the very low-level stuff, the real challenges are
> supporting the higher-level functionalities of multiple protocols (different
> updates/entities/worlds, etc.).
>
> - kripken

I'll take a look at Enet and presume it's interface is similar to
sirikata's and yours.

Cheers,