[Opensim-dev] "Friendly teleports" between the standalone sims

[Sean Dague]

On Thu, Sep 27, 2007 at 08:39:11AM +0200, Tleiades wrote:
>   just for a laugh, I've implemented so that the OGS Grid comms now have a Local Grid comm, and forwards all requests to it to see if it can be handled locally, if not, it accesses the grid.
> 
> 
> One second thought, I think we should be very carefull about the levels of indirections
> 
> The comms manager already has a lot, most of the various base classes
> in the inheritance chain try to implement complex logic, user simpler
> - and multiple - methods to the genric comms (be it the local or the
> OGS one), when the comms layer needs database access you will again
> see a lot of indirections.

Agreed.  I think we've got a couple too many layers of inheritance in
the current chain.  I'm always happy when people remove some of them. :)

> We have 2-3-4 different DB plugins (SQLLite and MySQL probably being
> more complete and stable), If you examine both the MySql and SQLite
> plugins, they are again staggered into a hierarchy of logic.
> 
> So if you tweak the local comms layer to attempt a local access first, and then divert to OGS in case you fail, you risk:
> 1) Duplicating the decision of wheter to uses local or OGS in two different layers of the application
> 2) Introduce - atleast increased -latency in the network
> communications, and that will cause the lag monster to appear.

Agreed.  I think our current model on walking through a list of loaded
plugins to do calls around the DB stuff is not good.  We really need to
pick one at load time, and that's our guy.

> I am pretty worried, we have a very flexible engine, with a lot of
> dynamically loaded assemblies, which - atleast on Microsoft -  will
> produce less than optimum compiled code, and we generally use a very
> inefficient network comms protocol (XML-RPC and REST). How can we get
> that to perform well?

Does the JIT really care if you are loading code on runtime?  Any
reference to performance information there would be appreciated.

> I would suggest that we:
> 1) Use .NET remoting for all our communications, out of the box .NET
> comes with TCP, HTTP and IPC channels. IPC is designed to be a local
> machine interprocess communications protocol. TCP and HTTP should be
> pretty self explanatory. The format of the messages can be controlled
> via formatters, out of the box .NET supports binary and SOAP, but an
> XML-RPC formatter is freely available.

The LL model is going to evolve into REST for communication to the Agent
Domain / Region Domain communication
(http://wiki.secondlife.com/wiki/Proposed_Architecture).  Using .NET
remoting for things outside of that (like Region <-> Region
communication) is a win, but we want to make sure not to evolve in a
completely incompatible way with where LL is going.

> 2) Drop local mode.
> 
> If we switch to a complete remoting based communications protocol, it will be possible to use high performance IPC remoting if we are running in stand alone mode, and stil delegate communications on a per server basis via the config files.
> 
> This way stand alone mode, is merely a question of using the right
> configuration. The gains are that we reduce the comlexity of the
> codebase by removing all the local comms stuff. and remove one layer
> of abstraction.

+1 on this approach.  If we can get local IPC fast enough, getting rid
of an extra layer of logic for us would be a good thing.

      -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________