[Opensim-dev] OGP/Capabilities

Wed Mar 4 09:38:40 UTC 2009

Diva,

basically, the concept of the EQ is something that pops up in almost any http-based (think AJAX) system to solve two-way communications.

At the bottom level, you can establish an tcp-ip connection. This is established from the client, but once established, it's bidirectional.

Problem is, if you demand continously established sessions with all resources (think distributed asset servers, inventory servers, user server(s) and neighbour regions) the total number of open connections needed for any given resource will eventually bring those systems down.

Also, if a connection is broken, you need to have some kind of resilience built into it, to bring the connection up again, and perhaps doing connection authentication anew.

So, what you can do is to try to 'tear down' and 'build up' the connection regularly, when it's not needed, or when there's been some kind of disturbance, essientially multi-tasking the sockets. This is one of the big wins with the statelessness of http.

Of course, the connection should be abortable from both client and server, as they have their own ideas of when a teardown might be prudent. Most oftenly, the server is authoritative on deciding when the EQ is 'empty', and the client is authoritative on when a 'scene update' is needed (if the window is minimized, that might happen very seldom).

Now, given this link, you can choose any session/request transfer protocol on top of it. Http 1.1 is suitable for this, especially given the 'keep-alive' mode.

Data can flow bi-directionally over a keep-alive link, which is basically only a tcp-ip connection with a http wrapper on top of it.

On top of http, you can choose any data serialization protocol. FORM POST, Xml Serialized, Xml-Rpc.

Even, god forbid, LLSD. And this is where I feel the LL clientstack starts to go west. Luckily, we can supply an EQ bi-directional http socket implementation not tied into the LL stack. (We could probably start with a bi-directional tcp-ip socket implementation, and attach an http 1.1 socket to that)

But as a transport solution, I don't think an "EventQueue" is a bad compromise, one just have to be god damn sure one knows what each layer in the chain is supposed to be responsible for, and what the actual resource use issues are.

And of course, think real hard if http (aka the 'holy grail of the 21st century') is the right session management protocol, and what should flow over that http socket.

Best regards,
Stefan Andersson
Tribal Media AB

> Date: Tue, 3 Mar 2009 19:31:32 -0800
> From: diva at metaverseink.com
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] OGP/Capabilities
> 
> Finally Linden Lab produced an interesting document:
> http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt
> 
> I think capabilities are the right concept here, and I'm pleased to see 
> them taking center stage in that document. In particular the hint at 
> inventory-related capabilities, which will allow secure inventory access.
> 
> I'm not sure I buy into some of the details, but the basic combination 
> HTTP+REST+Capabilities --> +1.
> 
> The Event Queue...well... It sucks. I think we need to look at 
> alternatives for posting things to the client. I can't believe there 
> aren't any; I think there are, but maybe they all come down to this, 
> event queues on the server-side, whatever their form.
> 
> If there are no better alternatives, then we need at least to rethink 
> what the EQ is all about. If the EQ CAP is not given to the regions, but 
> stays within the user's home system, that might work. Also, if there 
> would be several different *types* of Event Queues that might work well 
> too; so for example, we might give the social-net-related EQ CAP 
> (groups, IM, etc) to the social net component without compromising agent 
> transfers. The more I think about this, the more I'm convinced that 
> regions have no business in agent transfer activities, other than 
> negotiating the capabilities when agents come.
> 
> I really like that document, I must say, but it's strength is also its 
> weakness. It's just about the basic levels. It says nothing about how 
> those things are driven higher up.
> 
> Crista
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090304/a3a84471/attachment-0001.html>