In-world Object Server

HIyas Everyone,

I'm interested in setting up an in-world object server. The clients would be HOLO vendors based on Hiro's open source.

I pretty much have an idea of what I need to do to establish an llEmail server but I'm wondering if there is yet a "better" way to do this. I'm referring to http-in.

I still don't understand what Http-in can do and if it is relevant to what I want to do. And would Darien's DNS/GAE service play into this?

Any and all help greatly appreciated. Thanx!

Hi Zena,

HTTP-In is the way to go as its much faster than polling for Email messages.
Plus you can query the in-world object outside of SL.

You could use Darien's DNS service:


I've also recently released a system that demo's a Server / Client system using HTTP-In.
The LSL Remote Function system I wrote can be used for your needs, as one of the demo's shows the ability of sending a notecard from the server to the person who touches the client prim.

It uses the Grid URL Persister website , which runs on Google Appspot like Darien's, but is quicker to setup.

Hope that helps.

HIyas Pavcules,

I did come across the Grid Persister in my readings. I read up on it some more and check out your thread. Thanx!

Email in SL is like a message in a bottle. You can't know if anybody will ever receive it. Ok, it doesn't fail that often... but when it does, your script knows nothing about it.

Here comes http-in. It turns your script into a mini-server which can receive requests made of text and parameters. And it's accessible as well from an external browser --Not very useful for an object server.-- as from another script anywhere on the grid.

There no delay, except the time needed by your requests to travel through SL pipes. It's not that slow and you *always* know if it fails or not.

BUT there's a major flaw. You just can't "guess" the URL to access your mini-server. The URL is tied to the sim where your object is and to a key-like string that must be requested. It means you need a way to transmit that URL to the objects that will access it. Besides, this URL is temporary but, in your case of an object server, you only have to worry about region restarts and that's very easy to catch in the changed() event.

One way around the temporary URL, through Google App Engine:



In short, this allows the objects which access your object server to do it through a single invariable URL so that they never have to care about the real one.

Just read the first post. If all this doesn't fly waaaayyyy over your head, you're golden. You need to do all this just once and you can use it with different projects.

However, because of that need of an external server, that means you can't use http-in in a commercial product... unless you're ready to maintain a very public access to this external server.

in short, email may be a bit faster, but has no built in confirmation of receipt. http does, but it may be slower. both are going to require some sort of advertising of the email or web address, so as to be discoverable by the other end, and additionally e-mail requires poling on any receipt end....

not sure whether http or email will be more sim friendly with complete end to end confirmation, although the exchange is slightly more secure with email, and takes 1 or two fewer steps with http.

http will offer simpler options for outside website incorporation though.

Quote "Kaluura Boa":
"However, because of that need of an external server, that means you can't use http-in in a commercial product... unless you're ready to maintain a very public access to this external server."

And why not? There is people who have developed commercial products using HTTP-In. If someone has built a reliable and trusted system, I cannot see this being a problem.

Do a search on XStreet for the keyword: "http-in" < use the double quotes.


-----
Quote "Void Singer":
"in short, email may be a bit faster, but has no built in confirmation of receipt."

If you had a client prim that sent an email to the Server, the llEmail command delays the script fro 20 seconds. Plus on the Server end you need to be polling for the email messages, say once every one second. If you had multiple requests within a minute, you would have to wait at least 20 seconds each time.

One of the delays with using the external servers is that if the Server HTTP-In URL changes, the client prim would have to ask the external server for the new HTTP-In address again. But that would take a couple of seconds to do so.

I think this phrase was the crux of it
"unless you're ready to maintain a very public access to this external server."

although realistically, you need to do something very similar with email addresses (which can change when an object is rerezzed) although IIRC a sim restart won't change those, so it's a bit easier case to handle unless you plan on rerezzing your email server.


assuming all email requests are done from one script, yes... most people drop in serveral sub scripts to parse out emails faster... although this will be less sim friendly and is a good point... it pushes my leaning much farther toward http-in

When I tested Pavcules system, the HTTP-in Client script crashed on first try... "Too many HTTP requests too fast." Actually the script is broke.


edit:

So I tried a few more URLs from Grid Persister.... " ERROR: Could not find HTTP-In registation website." Doesn't look good.

On to Darien's DNS service via GAE. Am I correct in reading that I will need to maintain this service on my PC 24/7?

All the caveats to "communicating" in SL are just plain criminal!

I really don't need any offworld comm for want I want to do. I think http-in will work fine for me as long as I include an email subset to collect UUID@Locations and send new URLs.

This really has been an enlightening experience. SL doesn't seem so hi-tech after all this... lol

@Zena: No, you won't have to keep your PC on 24/7... If you go the GAE way, Google will do it for you.

@Pavcules & Void: There are 3 ways to deal with the temporary nature of the http-in URLs in commercial products:

1/ You ask your clients to have their own external server. Altho the procedure seems easy for us, it won't be so for everybody... Client service nightmare on the horizon.

2/ You provide a very public access to an external server. You can use the most secure system that haven't been invented yet but, in the end, you will still have to provide a public access to whoever buys your system. Besides, your clients may be concerned by privacy/security --You will be able to monitor every access-- and by reliability --They have no control on that external server.

3/ You use emails to synchronize the URLs in between your different objects and the whole system becomes as reliable as llEmail()...

4/ I just got an idea... using only http-in...

But don't get me wrong, I really think http-in is a good invention. I use it everyday with a DNS on GAE. I just don't like the way LL implemented the URLs.

Theoretically, if LL had used the UUID of the object in the URL, you would have to synchronize your remote objects with your central server object only once --assuming you don't derez it or move it to another region. Instead of that, we are here talking of DNS, URL synchronization and what-not!

I now understand that I would upload the DNS app to Google (max 10 apps).

not sure why I was included in that, but for either email or http-in server/client comms there's actually only one solution... advertise/discovery... doesn't matter if you use a web source something in SL, or sneakernet for that matter... as long as client can send to the server (or vice versa for some applications). the how is up to the designer, but I can imagine more than 3 specific ways, to achieve that.