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

Sean Dague sean at dague.net
Tue Sep 25 14:41:33 UTC 2007


On Tue, Sep 25, 2007 at 03:36:59AM +0200, Dalien Talbot wrote:
> Folks,
> 
> wanted to check your opinion on this.
> 
> I've slowly started hacking up the code to try out my idea of "friendly
> teleports".
> 
> The way I am playing with it is by making the "hybrid backend services" - a
> backend services class has the LocalBackEndServices as a class member, first
> redirects all of the calls to it, and then handles the "failure" cases  in
> InformRegionOfChildAgent, ExpectAvatarCrossing, AcknowledgeAgentCrossed,
> RequestNeighbourInfo.
> 
> The latter retrieves the regioninfo from the "remote regions cache" - hash
> indexed by the regionid, which would need to be populated within the flow of
> the said os* function.
> 
> The rationale for making the "overlay class" is to avoid the duplication of
> the functionality of  "same-server" functions which are there already in the
> local backend services - and have just the "intergrid" functions using the
> remoting which I snarf from the OGS1 backend services code.
> 
> Since the regionhandle seems to be quite tied to the grid coordinates, I am
> thinking of the following scheme:
> 
> 1) I add a new os* function, which would take the URL of the sim + the
> coordinates as the parameter. (could be a PATH_INFO-like scheme, i.e.:
> http://sim-domain-name/path_to_handler_or_sim_name_in_case_of_grid/x/y/z
> 
> 2) when the user script calls this function, the source sim A retrieves the
> info about the destination sim (grid) B via this URL (the mainly interesting
> stuff for the current implementation is the remoting IP/port) - but might
> change in the future. This is the point where the user might get a dialog
> box "do you want to teleport to ..."
> 
> 3) A and B need to negotiate a "temporary" regionHandle, which would be
> unused in both sims (grids).
> 
> 3a) A sends a request with the proposed region handle to sim B
> 3b) if this regionhandle is ok - then B responds to it, else it responds
> with "NAK", and proposes its own region handle.
> 3c) A does the same - if still not ok, selects the new temp region handle
> and the story repeats. If after N attempts we do not succeed, the teleport
> is declared as failed. If it succeeds, then both A and B have in the cache
> the info about the temporary handle.
> 
> 4) the user is sent to the target sim B using the
> scene.RequestTeleportLocation()
> 
> 5) once the user arrives, the sim (grid) B initiates a second teleport to
> the "real" region and signals back to sim (grid) A that the temporary
> location there can be cleared.
> 
> once the teleport succeeds, the sim(grid) B clears the temporary location as
> well. The temporary locations would be probably cutting off the chunk of the
> topmost X/Y coordinates.
> 
> This is a raw idea, I still need to test it further, but I think it might
> work..

This sounds quite nifty, and a very interesting way to address world
jump given the current arch limitations. :)  Perhaps we could specify a
certain incoming reserved region set for OpenSim grids to enable this
functionality between worlds.

> /d
> 
> p.s. I do not open yet the can of worms with the inventory, etc. :)

Yeh, I can imagine that wil be a lot of worms. ;)

     -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.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20070925/8ba1c16f/attachment-0001.pgp>


More information about the Opensim-dev mailing list