Is it possible to use experience key/value storage to communicate between two experiences in different regions?

[animats]

I doubt this is possible, but thought I would ask.

Use case: SL objects can  become HTTP servers. SL objects can communicate with each other via HTTP. But the inbound URL for an object is randomly chosen by the system, and (probably) changes at region restarts. So there needs to be some well-known place where server URLs are stored. The recommended way is an external server outside SL.

With the new enhancements to experience key/value stores, is it now possible for instances of experiences in different locations (such as a network of teleporters) to find each other via a key/value store?

[Love Zhaoying]

Since an individual Script can only be associated with an individual Experience, two separate scripts associated wiht two different Experiences would have to communicate the KVP's from each Experience with each other..right?

My brain hurts, so for an even simpler use-case, you could have two different Experiences in the same Region so long as they were in different Parcels..

But between Experiences, the two scripts would have to send messages to each other some other way since they can't see or update each other's Experience KVP's. Maybe an Intermediate script could send / receive messages from each, but I don't see why each script couldn't just message each other.

Hmm.

Hmmmmmm.....

ETA: Oh, I guess you meant two scripts using the SAME Experience in two different Regions!

Sorry, I thought you meant two DIFFERENT Experiences!

Edited May 31, 2023 by Love Zhaoying

[Love Zhaoying]

Too bad that it's not LSD (instead of Experience) KVP data, since that has an event..

[animats]

8 minutes ago, Love Zhaoying said:

the two scripts would have to send messages to each other some other way

It's the "some other way" that's the problem. Usually that means an external server. One of the Stargate systems is defunct because the external server shut down. Now the Stargates can't find each other. So this is a problem if you want to have a product but not operate a service to support it.

9 minutes ago, Love Zhaoying said:

Oh, I guess you meant two scripts using the SAME Experience in two different Regions!

That's what I'm thinking. Can you copy a land-scope experience to another region, so that it has the same UUID and shares key/value pairs? Is long-distance communication possible that way?

[Wulfie Reanimator]

9 minutes ago, animats said:

20 minutes ago, Love Zhaoying said:

Oh, I guess you meant two scripts using the SAME Experience in two different Regions!

That's what I'm thinking. Can you copy a land-scope experience to another region, so that it has the same UUID and shares key/value pairs? Is long-distance communication possible that way?

I thought that's how Experiences always worked -- I've just never been able to test it myself due to no access. Does @Lucia Nightfire happen to know/confirm?

[animats]

7 minutes ago, Wulfie Reanimator said:

I thought that's how Experiences always worked -- I've just never been able to test it myself due to no access. Does @Lucia Nightfire happen to know/confirm?

I'll have to ask her. She's an expert on key/value storage.

[Love Zhaoying]

I thought the default is: 1) You create an Experience. 2) Any script is associated explicitly with that Experience. 3) Land is also opted-in / associated explicitly with that Experience.

Seems like what you propose should work, but the scripts would have to poll a "flag" KVP or something to check for changes.

As far as this:

36 minutes ago, animats said:

47 minutes ago, Love Zhaoying said:

the two scripts would have to send messages to each other some other way

It's the "some other way" that's the problem. Usually that means an external server.

If they have the UUID of each other's Objects, or an the UUID of a "neutral object they both know about", they can just use..nothing. Darn! There's only llRegionSayTo()!

Oops.

Oh, wait. There's llEmail() and the email() event, there's just a throttle of 20.0 seconds between each message.

https://wiki.secondlife.com/wiki/LlEmail

Unless I missed something, llEmail() / email() is the only "cross-Region" communications supported between objects.

..and I almost always miss something.

[Wulfie Reanimator]

1 hour ago, Love Zhaoying said:

Oh, wait. There's llEmail() and the email() event, there's just a throttle of 20.0 seconds between each message.

https://wiki.secondlife.com/wiki/LlEmail

Unless I missed something, llEmail() / email() is the only "cross-Region" communications supported between objects.

Email has some reliability problems (mentioned in the wiki page), another option (which Animats mentioned) is URL/HTTP requests. Speaking of...

1 hour ago, Love Zhaoying said:

If they have the UUID of each other's Objects, or an the UUID of a "neutral object they both know about", they can just use..nothing.

Even if you had three objects and they all knew each others UUIDs and/or URLs, they are not static or reliable.

A couple years ago I went down a deep rabbithole of trying to create a "network" of objects across several regions, where each object ("node") in each region kept track of every other object in the network. If a new node wanted to join the network, it only needs to announce itself to any node, which would cause its URL to propagate to every other node, and in turn it would gain a record of every other node as well.

That seemed really promising. You had reliable cross-region communication as long as you had a node there. It didn't matter if a node changes its URL, it can update the rest of the network with the new URL. It didn't matter if multiple regions went offline during rolling restarts, the remaining regions would keep the network alive (even if only a single node survives), and all the other nodes would always be recovered after the regions came back online.

The unavoidable problem happens if the grid goes offline, or all nodes go offline at once by some bad luck. At that point you would have to setup the network by hand again, having to visit every node to share at least one URL with them so they can rejoin. Too much work for not enough utility.

Edited May 31, 2023 by Wulfie Reanimator

[animats]

27 minutes ago, Love Zhaoying said:

Oh, wait. There's llEmail()

Prim to prim email is strange. Also somewhat broken for a decade But worth a try.

I'm puzzled that prim to prim email across regions works at all. I don't think that SL has an index of every prim in the world by UUID. How do prims get found across regions? There's a global locator service for avatars (that's how IMs get delivered) but not prims.

The 20 second delay is supposedly only for emails to outside SL. (I use llEmail for trouble reports. For emails to outside SL, there's definitely a 20 second delay. Haven't tried within SL.)

[animats]

9 minutes ago, Wulfie Reanimator said:

A couple years ago I went down a deep rabbithole of trying to create a "network" of objects across several regions, where each object ("node") in each region kept track of every other object in the network.

That's what I'm thinking. Once you've found the network and know the URLs of the prims involved, you can use HTTP for communication. It's establishing who's where at startup and after resets that's hard. So this email/KVP stuff is just for restart and recovery.

Edited May 31, 2023 by animats

[Wulfie Reanimator]

11 minutes ago, animats said:

The 20 second delay is supposedly only for emails to outside SL. (I use llEmail for trouble reports. For emails to outside SL, there's definitely a 20 second delay. Haven't tried within SL.)

The 20 second delay is always there, but out-of-SL emails are additionally throttled to 500 emails per hour, per account. (So you can't get around that throttle by using multiple scripts, but you can within SL.)

Edited May 31, 2023 by Wulfie Reanimator

[Love Zhaoying]

29 minutes ago, animats said:

I don't think that SL has an index of every prim in the world by UUID.

Hmm..because UUID's don't change so long as an item isn't taken back into Inventory, and of course if it is no-copy?

35 minutes ago, Wulfie Reanimator said:

mail has some reliability problems (mentioned in the wiki page),

Missed it!

35 minutes ago, Wulfie Reanimator said:

another option (which Animats mentioned) is URL/HTTP requests. Speaking of...

Do not want! (Speaking for meh.)

35 minutes ago, Wulfie Reanimator said:

Even if you had three objects and they all knew each others UUIDs and/or URLs, they are not static or reliable.

But..but..they have to be for the "I, the parent, rezzed you, the child, so I know your UUID, and you know my UUID" logic to work! 

35 minutes ago, Wulfie Reanimator said:

A couple years ago I went down a deep rabbithole of trying to create a "network" of objects across several regions, where each object ("node") in each region kept track of every other object in the network. If a new node wanted to join the network, it only needs to announce itself to any node, which would cause its URL to propagate to every other node, and it would gain a record of every other node as itself as well.

That seemed really promising. You had reliable cross-region communication as long as you had a node there. It didn't matter if a node changes its URL, it can update the rest of the network with the new URL. It didn't matter if multiple regions went offline during rolling restarts, the remaining regions would keep the network alive (even if only a single node survives), and all the other nodes would always be recovered after the regions came back online.

The unavoidable problem happens if the grid goes offline, or all nodes go offline at once by some bad luck. At that point you would have to setup the network by hand again, having to visit every node to give share at least one URL with them so they can rejoin. Too much work for not enough utility.

Maybe we found a use-case for those gosh-awful Obelisks*?  You just know they are ebil transmission towers.

*See: "Asterisk and Obelisk".

Edited May 31, 2023 by Love Zhaoying

[Lucia Nightfire]

19 hours ago, animats said:

With the new enhancements to experience key/value stores,

What new enhancements?

19 hours ago, animats said:

is it now possible for instances of experiences in different locations (such as a network of teleporters) to find each other via a key/value store?

You're basically talking about URL persistence.

Of course it is possible.

You only need land in one region and land in another to test.

Allow the experience on each parcel.

In the RX object, store the newly created url in your experience KVP db and have the TX object read it and send an HTTP.

I've used my grid-scope experience to maintain communication between update servers and end-user products this way.

Many others have used their land-scope experiences to maintain communications between regions.

19 hours ago, animats said:

Can you copy a land-scope experience to another region, so that it has the same UUID and shares key/value pairs? Is long-distance communication possible that way?

Experiences are not bound to regions or land.

They are not like LSD which is object bound.

Data gets written to remote servers.

Land-scope experiences, currently, only need to be allowed and/or not blocked in the region/land in order for data r/w to be possible.

There was talk a few server meetings ago about removing region/land allowance as a requirement for KVP use to function with land-scope experiences.

If that happens, more content can use experiences anywhere for KVP r/w purposes.

Permissions usage will still require region/land allowance, though.

[Lucia Nightfire]

19 hours ago, animats said:

I'll have to ask her. She's an expert on key/value storage.

Nope, not at all.

I just stayed at a Holiday Inn Express once.

Edited June 1, 2023 by Lucia Nightfire