Setting up an in-game data server?

Two of my "main" projects I'm working on have come to a halt because I'm in need of a data-server to coordinate activities across sim borders, and hold data for days/weeks at a time. the problem is, I have no idea what I should be structuring a database server around. how should objects communicate with the server since the keys change every time they rez? how can a server keep track of individual players who re-rez game items 2 or 3 times a game?, how can I keep a persistant high-score for weeks/months (until someone beats it), and how can the server communicate back to the game items if the keys do change constantly when things are rezzed?

Sounds like you wanna delve into llEmail or XMLRPC. Email seems easier to me but has latency issues bigger than XMLRPC. On the other hand, I don't think email requires setting up a webserver like XMLRPC does. To be fair, I've not worked with either. The wiki pages on each seem pretty good.

If you want an in-world server system rather than an out of world one you rez a prim, get it's key and hard code that into the remote items so they can email to it.

A variation that can work with something that can afford a delay and if you have some sort of scriptable email, you set up an account that they email with a return address that's the key of your inworld server. Then if it needs re-rezzing for any reason you don't have to change all the scripts!

Bear in mind that serious 'server' stuff might well need an outworld end too - email and/or xmlrpc are then your friends (or your necessary evils maybe)

Actually, we've had a lot more success with Email than XMLRPC, in terms of latency. XMLRPC can be remarkably bogged down (although they are still running through the same central DB server, we've found that Email holds up better under load.) That being said, we are switching completely to XMLRPC these days, simply because we can get synchronous confirmation of message delivery.

Your going to need some application execution permissions regardless of the transport you pick. So, if your looking around for somewhere to host something like this, you will probably want shell access.

-Adam

I have some small experience with this, in my network tests: /54/52/73984/1.html

First, the need of real-time data communication with dozens of players with an inworld server is problematic. I found that SL will lose chat data when the chatter rises above a certain point. This lost data is not warned of, just lost. Adding a system re resend un-replyed to data makes thise worse, since it INCREASES traffic above the already broken threshhold...

Also, it sounds like you need to flowchart what data needs to be sent about, and narrow this data as much as possible. Once you know the data list you have to send, and what needs to be done with it, then you can create the code to do it.

Lastly, try and remember that working with scripts is like working with 20+ year old computers like the CBM-64. They are slow, act sometimes erratically, and have VERY limited memory. I think it's about 16K for both the variables and code together. (Am I right guys?)