[Opensim-dev] [Proposal] Expanded Grid Info Availability

[David Saunders]

Hey,

   Some good idea :)

     I am with a large active grid,  We have gotten 80+ avatars at events,
and yes it strains the code.  But seeing it work is great. We run about 100
simulators with 1 region each.  And we have split the grid services(robust)
between the public, what s is needed to service the client, and the private
 ports to service the simulators.  And the grid is consider private, and we
don't get the rouge regions connecting. Oh, before going on I will say the
strain is on the code and not the computers, The barely pass 25% usage.

 Ok, wit that any query for information should be throttled somehow, you
can count on the client to cache it.  The easy way is just make a cached
web service to handle the calls, offloading the simulator or rubust from
handling it.  This function can be written in only a few lines.

 One thing that might be nice is the ability to add more X headers in the
config file. (I never needed it to be added before but can think of some
need for it ) .  This way in the future when grid ops need another x-header
they don't have to crack open the code and modify.

UUIDs across grids would be nice except for who will control it? And who
will keep it from being polluted?   It also will put a new overhead on the
robust, for each object gets it own UUID, each copy of its own. So think of
having 10 avatars, building a region, each putting down a object in the
region. The region would have to call the central resource, could call
 100/min easy, Then put in an active grid, we can have 20-30 people
building across the grid at once.  If we have to make an internet call to a
server , would add a new bottle neck into the cog of things.

I would think the hyoernet people would of resolved this to some extent.
And we can be happy filling up out asset server with all our little
objects. (7,000,000+ for 1600 avatar)

So, a work around for this would be talk to the grid operators about adding
a properly written php script to run on the web server that will allow read
access to the regions table.  To do the following functions:

1> Do I have a region  on this host name / IP
2> Is this 'Region Name' on this host/ip

 you can implement immediately.
    Just watch out for the snag of reverse dns may return the wrong host
name.  You cant count on a few host names, osgrid can have many 100's and a
simple grid can have 1 or 2.
 on our grid all the hosts are names and not IPs in the region table, And
should reverse back to us EXCEPT for remote hosted simulators  :)   So, can
be bit confusion on what you need to do.


David.




On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <opensim at haravikk.me> wrote:

> This is a subject very much related to my topic on IP and region
> validation, and the proposal is very simple; the idea is to make it easier
> to find out which grid an object or avatar belongs to, as this is useful
> for a variety of reasons.
>
> It's already possible to get this information with some os*() functions,
> but they have a current threat level of Low or Moderate, placing them above
> the default of VeryLow and thus preventing them from being widely
> available. However, I'm not convinced that the threat level of these
> functions actually needs to be so high, as the information can be obtained
> by other means, it just seems like an unnecessary restriction on scripts.
> You can view the full proposal here:
> http://opensimulator.org/wiki/User:Haravikk_Mistral/
> ExpandedGridInfoAvailability
>
>
> I'm interested in feedback about which functions should/should not have
> their threat level downgraded, and also about my proposed addition of a
> header on llHTTPRequests() that identifies the grid.
>
> In discussion on IRC there was a question raised about privacy,
> particularly tracking between grids, but I'm not sure this is a problem;
> currently hyper grid travels works on the assumption that an avatar's UUID
> is unique, which scripts are free to do as well, in which case they are
> already able to track an avatar fairly reliably if they want to. Thing is
> though, to do this they'd need to have an external service in common, and
> devices spread about widely enough across different grids to get any kind
> of meaningful tracking, and even then, what can be done with this
> information is fairly limited. Knowing what a user's home-grid is won't
> make this any easier; the only difference is that with knowledge of the
> grid you can be certain there is no cross-grid UUID collision (i.e- UUID
> uniqueness is a bit less uncertain), it opens up no real capabilities to
> track avatars that I can see, and there are better ways to prevent tracking
> that could be implemented if it were a problem.
>
> However, the advantage of having this information more readily available
> is that it becomes possible for in-world devices to handle avatars
> differently depending upon whether they are from the current grid or not.
> It would also, crucially for me, make handling of data on a web-service
> much easier, as it becomes possible to easily partition data by the grid it
> belongs to, and to handle crossover (i.e- travelling avatars) more
> intelligently.
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>