See EVEs economy for example - there are local, regional and global markets, quite complex, realtime and like ours totally player-driven. Can you imagine such a system like EVEs market-system performed on a set of GLOs?- Not really, or are you able to?
Ragosch
realtime is a relative concept around here, I’m not sure if I’m asking my questions wrong or I’m simply not getting responses. to keep from matters getting grim, I’m just gonna qoute jeff, these where in response to something else but the problem is somewhat the same.
There it is - thank you very much - I have totally overlooked the ability to open a socket and get callbacks to a special GLO - you saved my day, thank you once more. Nevertheless it would be a good solution to use just the underlying database directly from the SimTask; anyway it can be done using these raw sockets and that is what’s important … cant believe I didnt see that, I have looked it over and over but didnt see those sockets … strange sometimes.
Ragosch
So, more or less, you are suggesting using GLOs for some of game objects, while leaving market to be totally outside of space managed by SGS ? How do you plan to do transactions then, like:
Get market offer
Get player GLO
Check money and deduct from player if needed
Put item into player inventory
Remove market offer
Imagine that after doing a commit on market database, SGS decides that your task is running too long and kills it, not committing transaction on player GLO. I don’t think that you are allowed to do any kind of operation modifying any kind of state inside jvm or outside of it from inside a SGS task and still be safe from reexecution perspective.
All this starts to smell very EJB to me, two phase commits, container managing transactions for all the data sources, etc, etc. And we all know where EJB is as far as performance is concerned…
I think of updating the extern database asynchronously, not synchron with the running SimTask.
First the economic transaction is made inside the SGS and a GLO is constructed listening to Raw Socket Events ready to report the transaction to the database if the socket connection will be available. The last action on the SimTask is opening the socket connection registering the listening GLO; then the task ends.
As soon as the socket connection will be available, the GLO containing the transaction will be “started” by SGS and sends the economic transaction as an SQL command through the socket to the database, closes the socket and thats it so far - should be pretty fast, so no problem with timeout here. Hm, maybe I should use an XML document instead of a SQL command here in order to be able to transfer some meta data with it at the same time.
The only problem is how to get rid of this GLO again. It was started by an event, therefore it was accessed by GET and I cant kill it from inside the GLO because it would be written again when the task ends. Any ideas how to get rid of it safely after execution?-
Hm, maybe I should not kill those GLOs, because I could use them in the case I need to synchronize the external database again during a sheduled downtime for maintainance purposes. If they are still there, I could use them to redo all transactions from the last safe point of the database to the current state of the SGS and create a new safe point this way … much better, just need to name those GLOs properly.
Thank you for your question, abies, it spend me a new idea on this 
To answer your question. I dont think of separating the market from the SGS. I just wanted an instrument to analyse the market in a sophisticated way outside of the GLO pool. The external economic data in the database is 100% redundant, just for supplying sophisticated fast answers to complex questions without the need to investigate thousands of GLOs. The database is not just covering market information, but also logistics and other important economic informations.
Ragosch
Btw: the clients would contact the extern database directly, just querying it to get sophisticated answers. There is just a reporting connection planned from the game logic to the database, actually just updating it, never requesting data from there.
Ragosch: thanks so much. i understands that currently each host contains onli 1 slice which is capable of handling 200-500 users, depending on the game and hardware. but i wonder if 2 hosts can access the same ObjectStore? If yes, how can i do that?
The context to access the ObjectStore from any other GLO in the system is the SimTask object which you can get by a call to the static method SimTask.getCurrent() for example with the line
SimTask task =SimTask.getCurrent();
Once you have this task you need a GLOReference to another GLO. Lets say you want to find and work on a GLO named “myTestGLO”. First you get the GLOReference by
GLOReference ref = task.findGLO("myTestGLO");
Once you have this reference you access the associated GLO via this reference using the task again as context like this (lets say this GLO would be of the class MyTestGLO):
MyTestGLO glo = ref.get(task); /* requesting a write-lock on the GLO */
You see you never need to worry about where the ObjectStore actually is. If you have a GLOReference you can access the assiociated GLO at any time through the SimTask object.
Ragosch
hmm… ya, i kinda get wat u means by this. ie. 2 GLOs within the ObjectStore.
From what i understand, if 2 SGS, each lies on a separate work station or server, SGS1 talks to ObjectStore1 and SGS2 talks to ObjectStore2. there is no comm from SGS1 to ObjectStore2 and SGS2 to ObjectStore1 right?
is there a possible way for these 2 seperate work stations(different IP) to access a common objectstore?
No, you missed the concepts here. There is only 1 ObjectStore for 1 game. Even it might be processed on a huge server-cluster. All slices access the same ObjectStore. And because you never know on which slice a GLO is actually executed you access this unique ObjectStore through the SimTask object using GLOReferences.
You dont need to synchronize anything here, because there is only 1 ObjectStore which is accessed from all slices. SGS takes care of the transactions you do within 1 task. All changes you do are transferred to the ObjectStore on an all-or-nothing base. If execution of a task takes too long it might be aborted and requeued. Nothing has changed in the ObjectStore then; it is guaranteed that all changes will take place at the same time - that is meant by transactional-safe database manipulation.
If several games are installed on the same SGS each game has a separate ObjectStore even all installed games are executed on the same server-cluster. There is no way to access the ObjectStore of another game directly. Your connection to the ObjectStore of your game is the SimTask object. It provides all methods needed to access it. But it is important that you do not store a reference to the SimTask object and reuse it in another task; you need to request the current SimTask newly in every task using SimTask.getCurrent().
Ragosch
thanks. i understands this concept ;D
what i actually referring to is…
workstation 1(eg. of fake IP: 155.69.111.111) -> SGS installed -> Shooting Game
workstation 2 (eg. of fake IP: 155.69.22.22) -> SGS installed -> Shooting Game
so you can see that the SAME Shooting Game has been installed in each of the SGS on IP:155.69.111.111 and IP:155.69.22.22.
now my question: currently within SGS, there is no way for players logon to IP:155.69.111.111 to see players logon to IP:155.69.22.22 right?
I really cant understand what you are up for. Are those 2 work stations part of the same server-cluster (or THE server-cluster) or are you talking of separate systems running separate instances of SGS on each of them?
In the first case there is ofcourse no connection between both game, because it would be like I am running a game with SGS on my computer here and you are running a game on your computer there - so why should they talk to each other by itself?
In the second case if both work stations are part of the same server-cluster just 1 SGS is running on them and there is 1 ObjectStore per game. So if you install the shooting game once on the SGS all players logged in to any computer on the cluster will use the same ObjectStore. But if you install the same game twice or several times on the same SGS with different game IDs every instance of the game on the SGS will get its own ObjectStore and there is no internal communication between those games even all are using all servers in the cluster concurrently.
You could establish a communication gateway from game to game using a special “client” which logs in to all the games and transfers data from one game to the other - but that would be a very unsafe and limited way of communication; to say it more clearly, it would be a hack.
Maybe tell us about the idea behind your wish to do that in this way … maybe we can find some better solution for it.
Ragosch
Allow me to intrdouce some terminology that may help.
In a full SGS abck end there are many physical computers-- we will call them “boxes” fir the purpose of this discussion.
Each box runs what we call a “slice”. Each slice has a communications tier, a game logic engine, and interfaces to object stores. It does not contain the Object Stores themselves, they are external and adressed by many slices at once. Each slice can have N games installed in it. Each game references its own object store and has iots own channel name-space.
The same game, installed into muiltiple slices, all reference the same object store and channels. They are a;; efectively “one application” running across many boxes. This is how we scale and fail-over in the case of individual box failures.
Now the SGS server you get as part of the SDK does NOT do this. It has the entire object store in it, not just an interface. This is pusposeful. The SDK server does NOT scale, does NOT fail-over and is NOT intended for production use.
This kind of confuses me. What is the term “installed” here?- I thought of it like that installing a game means the XML deployment descriptor is assigned to each box while the boot GLO (which might install the game world if needed) is just called once during the cluster is booting, not for each and every box. Clients would know of those boxes from the discovery.xml and can login to one of them. So what exactly is the term “installed in a slice” here?
Ragosch
Jeff, might it be possible to get direct access to the underlying database of the SGS maybe via a method in the SimTask object much in the way like a socket is opened from there yet, but the message would be an SQL request to it. The reason I ask here is that the underlying database is maybe highly accessible (you said HADB, I looked at it and it seems to be a really safe technology) and data you want to store outside the GLO pool (i.e. the ObjectStore) would be able to make use of these super-safe storage and SQL queries.
Breaking down the game logic and data into GLOs is ok as far as this data is small enough per GLO (because it is loaded and stored in full), but it becomes a pain and a bottleneck if you need to access mass data this way and want to get meaningful information out of it. What is easy using SQL on a real database becomes a pain when it needs to be performed on GLOs - and because of the short-lived nature of a task I dont believe in any sophisticated information to get out of hundreds or thousands of GLOs. Breaking this down into task and child-tasks does not help here because using another task means there is no longer transactional safety for the whole query operation.
I hope I have explained it good enough to show the need of external database access and why we want to use the (maybe highly accessible) database system in the SGS.
Ragosch
Jeff:
is it becos the SDK server is limited to 1 slice tt’s why it does not scale?
as the SDK server does NOT scale, will the SGS SDK works for server clusters?
It will, because all those APIs in the SDK never have anything to do with the process of farming out GLOs on a server-cluster. The server-cluster itself is transparent to your development as well as the underlying database for the ObjectStore.
Ragosch
haha. okok. thanks. i will try it out after i get myself familiarized with the SimTask operations.
No. A slice is the stack of softare that runs on a box. The boot GLO is called for each slice. This is necessary to register your callbacks on that slice (trust me,)
FIrstTime however is only true ONCE across all boots of all slices as long as the obejct store is not cleared.
Its an interesting thought. Unfrotunately exposing the database would make the ObjectStore interface in the system SQL specific. Currntly it is not and I dont really want to put that limit on an implementation.
How to do RDBMS stuff though in general is an interesting question. Let me ponder it a bit…
We would not want to access the ObjectStore by SQL (the ObjectStore keeps being untouched as before), it would just be adding another option to use the underlying (highly accessible?) database as RDBMS. And because SQL is most common I thought of an SQL interface in addition to the already existing methods in the SimTask object - so from my perspective this is not a limitation but a new option, which would make more efficient use of the maybe expensive hardware (=HADB + dedicated database servers). HADB has no other use than serving as a highly accessible database system … but SGS is just using it like a very expensive hashtable.
Ragoschj