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

Thu Sep 27 19:51:04 UTC 2007

On 9/27/07, Sean Dague <sean at dague.net> wrote:
>
> 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. :)

partially agreed :) the question is how much would we want to optimize and
when. From my studies the calls to the backend services are only happening
during the region changes - from my SL experience this is a tiny fraction of
the time spent. As such - isn't it a premature optimization in this case ?

I would see the backend services model (backend services not as "UGA infra"
but as a specific class which is mostly responsible for the inter-region
movement) as possibly being three layers:

layer 1: "my" instance. Handles all the interregion stuff for this running
instance of the sim. (since we can have multiple regions)
layer 2: "this administrative domain". This is either a no-op in the case of
a standalone mode (since this administrative domain == this instance), or
OGS in the case of grid services.
layer 3: "interdomain". This handles either inter-sim or inter-grid or
inter-sim-grid operations.

interdomain might have some similar operations do the lower layers, but this
is merely at the initial phase when the inventory / identity are not dealt
with. Afterwards it is a distinctly separate layer, possibly with its own
protocol.

UGA-wise, there are probably only 2 layers:

layer 1: this administrative domain
[layer 2: interdomain] - as i mentioned - not considered so far.

> 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 think Tleiades had a different notion in mind, which  I have hopefully
clarified with the above layout. The current stuff we are playing with is
highly proof of concept, and needs to be shaped. Not sure how the folks feel
about the 3-level model, but IMHO it leaves very little room for the
confusion on where to use the OGS.

> > 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?

Again - I have a feeling we are doing the premature optimization here. :)
The reason I thought that the interdomain teleport is an important thing, is
that
I do have some questions about the UGA being a single point of failure.
Indeed someone might host a highly redundant and powerful grid, but then I
have some doubts whether it will remain *free*. And it seems we already have
LL being the candidates for that post anyway :)

> 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.

depending on whether the above hierarchy is interesting or not, there could
be differing approaches. Maybe I misunderstood something (after all, I do
remember myself being a strong advocate for doing everything via the
loopback networking *only* in grid mode in the first place :) - but maybe
the discussion again goes into the direction of question of UGA - while I
was talking about the very specific component, responsible for inter-region
movement of agents.

the interdomain functionality is something that we could turn on/off based
on the configuration setting - but imho it is still different from the
functionality from the same-domain which the whole LL grid essentially is.

Optimization-wise, I think it is important to first make it well-structured
and clear. We can always collapse the layers for the performance sake later
on.

If we feel the certain path of code is badly suboptimal, may be interesting
to profile the code based on the typical usage pattern and see where we do
need to do the optimization, and where we do not.

Just my 0.002 euros.

/d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20070927/e2a2cb7b/attachment-0001.html>