Obect to Object Communictions across Multiple Sims?

I have an idea for a product which would require some objects to be able to communicate to each other from across many sims - potentially, from anywhere in SL to anywhere else in SL. However, I'm having some trouble finding the exact info I need right now, I've checked some of the various wikis to piece together what I'm looking for but I'm hoping some more-knowledgable scripters can help me out.

It looks like email is my only option for direct object-to-object communication, but I forsee a number of problems with the implementation, primary being the potential for change of key if something is re-rezzed.

So now I am thinking that relaying the communications through an off-world server might be a better bet - On rez I can have all objects 'check in' and provide their new key, with an http post. Then when one object wants to send a message to all the others, it could use an http post to the off-world server, which would then use xml-rpc to relay the message out to the other objects. And the other objects' reply would be captured in the xml-rpc sessions, and the replies could be relayed back to the first object with xml-rpc as well.

That's what I think would be the fasted method, but now I'm concerned about potential lag... do http posts or xml-rpc requests impose significant drains on the sim resources? These things wouldn't be happening all the time - once per hour would be a 'busy' day, for what I have in mind.

Thanks very much!

-Atashi

You can construct a similar system in world using an in world server. You rez it once and then never de-rez it. Thsi gives you your fixed ID for emailing.

Well, the answer is not email. I did a test recently (and didn't retest, so it might have been a fluke that day) but emails took from 40 to 60 minutes to be delivered from RL to ingame object. EEK!

I plan to test again, and hope results are better, but I still doubt it would be appropriate for real-time communications.

Email to/from external servers is very slow at times. However, internal object-to-object emails are almost always very quick. Thus, for what the OP is asking about, it will work just fine. It is annoying to set up and use, yes, but it does work pretty well.

To resolve the key-changing issue, you can use some kind of object GNS system. W-hat has a free one, and I am finishing up one of my own which will be for-pay.

Edit: *swats typo fairy with keyboard*

Thanks everyone for the input! I'll give email a try and see how it goes.

-Atashi

I'm using mail. I did not want to rely on an external HTTP server. Over the years, an external server may go away, the code may be broken by an update, a change in software, in site policy. And oops! thousands of SL objects stop working...

If XML-RPC were accepted from in-world, i would have choosen this way. But Linden blocks RPC requests coming from inside. I think they are afraid by automatic communications, as they are by automatic asset creation. Linden makes data processing impossible.

With mail, I have reliable and decently fast (1s) communication. This is enough for avatar/system interaction. When the network is fully up, I dump the server's client keys database and save it to a notecard. If the server happens to be derezzed, the new server can read the notecard and mail the clients to hook-up with the new key.

Heh. I use an external HTTP server for several of these reasons. I've been running a stable website for years (despite many changes in underlying hosting locations, hardware, and software), and the stability of it vs. SL itself convinces me that the more work I can do on my own servers, rather than relying on in-game scripts, the more stable and reliable things will be.

The external server can go away, a quick change to the DNS records and everything heals. Perl/PHP code seems less likely to be broken by updates than LSL. I completely control what software changes occur, and when. I set site policy myself. Heck, every reason you listed is a reason why using the external HTTP server seems like a better idea to me. The only downside is the added expense of hosting your own server and/or renting rack space in a hosting facility, and that's quite cheap these days.