[Opensim-dev] Event Queue

[Hurliman, John]

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev- 
> bounces at lists.berlios.de] On Behalf Of Cristina Videira Lopes
> Sent: Wednesday, December 03, 2008 9:40 AM
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] Event Queue
> 
> Apologies in advance for bringing up everyone's favorite hate topic,
> but having spent most of yesterday tracking TP/crossing problems
> (again), I can't help but bringing this up to a wider audience. I know
> everyone hates the EQ. As it stands, there are several broken elements
> with the EQ in OpenSim, beyond the obvious bugs caused by its
> management. I'm just wondering if there is something here that I'm
> completely missing, or if this is really this bad:
> 
> 1) It's implemented as an optional region module (!!!), configurable in
> OpenSim.ini (!!!). That explains why, for example, I could not reproduce
> crashes that other people have reported with older viewers. It turns out
> that those people are not just using older viewers; they are using
> OpenSim servers configured with EventQueue=false. A complete
> miscommunication.
> 
> 2) It's implemented as an optional region module -- the sequel. It is
> being considered a [optional] part of the Region Environment,
> something a region may or may not do. I'm afraid, this is the incorrect model.
> The server side doesn't have any choice on this, if it wants to
> interact with the current version of the LL viewer. The EQ should be
> hand-in-hand with LLClientView. After all, it's the new channel of
> communications between a server and the LL viewer. Things that used to
> go over UDP are now sent via the EQ, period, no choice. Region
> Environment should be completely oblivious to that change. As it is
> now, this pattern occurs all over Region Environment classes:
> 
>             IEventQueue eq =
>             [scene.]RequestModuleInterface<IEventQueue>(); if (eq !=
>             null) {
>                 // send the event over EQ
>             }
>             else
>             {
>                 // call the right IClientAPI method to send the event
> [over UDP]
>             }
>  This is infecting the server side with things that should be purely
> client side. It's a horrendous way of getting at the question "what
> version of the LL viewer are you supporting in your region?". If there
> is such a thing as a wrong question to ask, this is one of them. If we
> want to support viewers with older communication stacks, then let's make
> that explicit in OpenSim and subclass LLClientView for the N previous
> versions of the LL viewer's communications stack. Region Environment,
> and the whole of the OpenSim framework, should be insulated from that
> mess, that's what the IClientAPI is there for. No OpenSim.ini
> configuration variables, other than the already existing one:
> clientstack_plugin="OpenSim.Region.ClientStack.LindenUDP.dll"
> 
> What will happen when Rex comes along? ... what version of the LL
> viewer is that based on? ...
> 
> Sorry for venting! I'm just sending this out to find the answer to
> these three questions:
> 
> a) Am I missing something?
> 
> b) Are there any objections to placing EQ under
> OpenSim.Region.ClientStack.LindenUDP? (besides that name now being
> somewhat incorrect)
> 
> c) Should OpenSim be backwards compatible with viewers forked off from
> older LL viewers *for the specific aspect of communications*? If so,
> what design pattern should be used?, subclassing or alternative code
> paths inside methods?
> 


In light of the security exploits found in the UDP protocol with RegionCrossed and EnableSimulator packets, there's a strong argument to be made for dropping support for insecure clients completely. Any client that has support for the event queue (any client released in the last year and a half I think) can receive packet events from the event queue, and recent clients can *only* receive certain events from the event queue. The event queue has been a fundamental part of the Second Life(tm) protocol for quite a while and IMO should be baked into the client stack right next to the UDP packet handling as a non-optional component.

I share the wider sentiments that doing reverse HTTP to send event messages to clients is a poor design decision. However, time would be better spent designing an improved protocol and modularizing the GPL client or developing a new client where the protocol stack can be manipulated.

John