<br><br><div><span class="gmail_quote">On 9/27/07, <b class="gmail_sendername">Sean Dague</b> <<a href="mailto:sean@dague.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sean@dague.net</a>> wrote:

</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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.

<br>><br>><br>> One second thought, I think we should be very carefull about the levels of indirections<br>><br>> The comms manager already has a lot, most of the various base classes<br>> in the inheritance chain try to implement complex logic, user simpler

<br>> - and multiple - methods to the genric comms (be it the local or the<br>> OGS one), when the comms layer needs database access you will again<br>> see a lot of indirections.<br><br>Agreed.  I think we've got a couple too many layers of inheritance in

<br>the current chain.  I'm always happy when people remove some of them. :)</blockquote><div><br>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 ? 

<br><br><span class="gmail_quote"></span>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:

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

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

<br><br>UGA-wise, there are probably only 2 layers:<br><br>layer 1: this administrative domain<br>[layer 2: interdomain] - as i mentioned - not considered so far.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> We have 2-3-4 different DB plugins (SQLLite and MySQL probably being<br>

> more complete and stable), If you examine both the MySql and SQLite<br>> plugins, they are again staggered into a hierarchy of logic.<br>><br>> 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.

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

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

<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I am pretty worried, we have a very flexible engine, with a lot of<br>> dynamically loaded assemblies, which - atleast on Microsoft -  will

<br>> produce less than optimum compiled code, and we generally use a very<br>> inefficient network comms protocol (XML-RPC and REST). How can we get<br>> that to perform well?</blockquote><div><br>Again - I have a feeling we are doing the premature optimization here. :) 

<br>The reason I thought that the interdomain teleport is an important thing, is that <br>I do have some questions about the UGA being a single point of failure. <br>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 :)

</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Does the JIT really care if you are loading code on runtime?  Any reference to performance information there would be appreciated.

<br><br>> I would suggest that we:<br>> 1) Use .NET remoting for all our communications, out of the box .NET<br>> comes with TCP, HTTP and IPC channels. IPC is designed to be a local<br>> machine interprocess communications protocol. TCP and HTTP should be

<br>> pretty self explanatory. The format of the messages can be controlled<br>> via formatters, out of the box .NET supports binary and SOAP, but an<br>> XML-RPC formatter is freely available.<br><br>The LL model is going to evolve into REST for communication to the Agent

<br>Domain / Region Domain communication<br>(<a href="http://wiki.secondlife.com/wiki/Proposed_Architecture" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.secondlife.com/wiki/Proposed_Architecture

</a>).  Using .NET<br>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.

<br>><br>> This way stand alone mode, is merely a question of using the right<br>> configuration. The gains are that we reduce the comlexity of the<br>> 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.</blockquote><div> 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.

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

<br><br>Just my 0.002 euros.<br><br>/d<br><br><br><br></div></div><br>