Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Scattered storage model?  (Read 8666 times)
0 Members and 1 Guest are viewing this topic.
Offline Ragosch

Junior Duke




Java games rock!


« Reply #30 - Posted 2006-05-31 08:31:31 »

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
Offline Jeff

JGO Coder




Got any cats?


« Reply #31 - Posted 2006-05-31 21:51:43 »

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.





Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ragosch

Junior Duke




Java games rock!


« Reply #32 - Posted 2006-06-01 00:50:36 »

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.

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ragosch

Junior Duke




Java games rock!


« Reply #33 - Posted 2006-06-01 01:18:22 »

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
Offline emerald

Senior Newbie





« Reply #34 - Posted 2006-06-01 06:33:33 »

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.

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?

feelin rusty
Offline Ragosch

Junior Duke




Java games rock!


« Reply #35 - Posted 2006-06-01 07:00:55 »

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
Offline emerald

Senior Newbie





« Reply #36 - Posted 2006-06-01 07:58:12 »

 Smiley haha. okok. thanks. i will try it out after i get myself familiarized with the SimTask operations.

feelin rusty
Offline Jeff

JGO Coder




Got any cats?


« Reply #37 - Posted 2006-06-02 00:49:40 »

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.

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #38 - Posted 2006-06-02 00:52:32 »

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.



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...

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ragosch

Junior Duke




Java games rock!


« Reply #39 - Posted 2006-06-02 08:33:20 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Duke





« Reply #40 - Posted 2006-06-02 09:57:05 »

HADB has no other use than serving as a highly accessible database system ... but SGS is just using it like a very expensive hashtable.

Very expensive hashtable with transactional behaviour. 'transactional' is quite a major point I suppose.

Artur Biesiadowski
Offline Ragosch

Junior Duke




Java games rock!


« Reply #41 - Posted 2006-06-02 10:27:24 »

Correct, I forgot to mention that. But it is still like using a Mac truck for the transport of a six-pack.

Ragosch
Offline Jeff

JGO Coder




Got any cats?


« Reply #42 - Posted 2006-06-04 02:51:16 »

To be complete: a highly scabalbe, transactional, fault tolerant and snapshottable hashtable Cool

.Id say we are uign about 50% of its capabilities.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ragosch

Junior Duke




Java games rock!


« Reply #43 - Posted 2006-06-04 04:36:59 »

what do you mean by snapshotable?
Offline Jeff

JGO Coder




Got any cats?


« Reply #44 - Posted 2006-06-04 08:16:52 »

Being able to pull a referntially integrous external backup without bringing the system down.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ragosch

Junior Duke




Java games rock!


« Reply #45 - Posted 2006-06-04 09:14:25 »

Hm, yes, it is true, that is a nice feature too. But I would not say that those missing relational database features, query and manipulation abilities would just count as 50% of the database features. If you are used to express and query your data in relational tables you will heavily miss those if they are no longer there.

Ofcourse some of those features could be intergrated using an external database from inside the SGS via the SimTask.openSocket(....) method and the associated callbacks via a GLO, but it would call this GLO 3 times for a single query, while an implementation via a new SimTask.startSQLQuery(....) method could do this by just invoking the callback GLO once (maybe with an automatic deletion of this GLO when this callback task ends). Wouldnt that be a much more efficient way to use relational database features from inside the SGS?

Ragosch
Offline emerald

Senior Newbie





« Reply #46 - Posted 2006-06-05 08:00:59 »

To be complete: a highly scabalbe, transactional, fault tolerant and snapshottable hashtable Cool

.Id say we are uign about 50% of its capabilities.


jeff, i would like to know more about the backend objetc store(HADB). wonder if http://www3.java.no/JavaZone/2005/presentasjoner/ManyiLu/ManyiLu-JavaZone.pdf has some similarities to the ObjectStore at SGS backend?

feelin rusty
Offline Ragosch

Junior Duke




Java games rock!


« Reply #47 - Posted 2006-06-05 16:42:28 »

That link is also that info I read about the HADB technology - it is a highly accessible database capable to repair itself when an error occurs. Jeff said, HADB is planned as backend storage in the "big" version of a SGS installation, afaik.

Ragosch
Offline Jeff

JGO Coder




Got any cats?


« Reply #48 - Posted 2006-06-07 20:47:01 »

To be complete: a highly scabalbe, transactional, fault tolerant and snapshottable hashtable Cool

.Id say we are uign about 50% of its capabilities.


jeff, i would like to know more about the backend objetc store(HADB). wonder if http://www3.java.no/JavaZone/2005/presentasjoner/ManyiLu/ManyiLu-JavaZone.pdf has some similarities to the ObjectStore at SGS backend?

HADB is indeed a technolgoy we are  looking at striongly for  objectstore implmementation.
We have some large scale scalign concerns that may result in our adding to the HADB model to support.  This is all in heavy research right now.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline tigeba

Junior Duke





« Reply #49 - Posted 2006-08-21 22:46:32 »

How about a criteria query type interface that hangs off SimTask with the results redirected to either a callback or a channel?

Sorry for the thread necromancy Smiley
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (38 views)
2014-10-17 03:59:02

Norakomi (29 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (56 views)
2014-10-14 00:39:48

TehJavaDev (55 views)
2014-10-14 00:35:47

TehJavaDev (46 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!