roadmap?

[eltanno]

Is there a roadmap?
Where are you on the development?
How much is left to do?

I am very interested in SGS but find it had to commit to anything without knowing where it is heading. Can you give us an indication of when you expect to have a full release?

[Jeff]

The road map is in development.

The road map TO the road map says I should know more in about a month.

[Jeff]

I should add that if you have a serious, funded project and need information sooner it *might* be possible to release more of our internal current info under NDA.  For that you'ld want to talk to Chris.

Games published by our own members! Check 'em out!

[emerald]

I should add that if you have a serious, funded project and need information sooner it *might* be possible to release more of our internal current info under NDA.  For that you'ld want to talk to Chris.

yes. we're trying to see how PD can be used to develop, implemented and deployed games, which we would make proposals for fundings.

Currently i'm looking at how to integrated all the different clients ie. J2SE, J2ME, C++ (these 3 are currently supported by PD) but others such as ActionScripting from Macromedia Flash, Top Script, PHP...  i was thinking of creating a servlet/web service to provide a common API interface to all the different interfaces at the front end. Do you think it's possible? But i heard that the extension docs are coming in the release 2. so it's soon right?

as for the load balancing: take for example, i have multiple servers at the backend, i will have one synchronizing server to syn all the data with the rest of the servers. This syn server will then dynamically generate the Discovery.XML to determine which server has the lowest load for connection. We can then code our own UserManagerPolicy to implement the load balancing in the SGS. It this ok too?

[Ragosch]

If I have understood Jeff right, it should be possible, but he also said that the server will have highest priority when it comes to the decision which server to use (or atleast SGS might force the client to disconnect and login again on another server). Hope I have interpreted Jeffs statements correct this way.

Ragosch

[Mr_Light]

as for the load balancing: take for example, i have multiple servers at the backend, i will have one synchronizing server to syn all the data with the rest of the servers. This syn server will then dynamically generate the Discovery.XML to determine which server has the lowest load for connection. We can then code our own UserManagerPolicy to implement the load balancing in the SGS. It this ok too?

Loadbalancing and syncing is what the SGS is for afaik thats all already in place. ( using a differend strategy then outlined)

[Ragosch]

Synchronization of data is given because every mutation of the objectstore is done in a transactional (atomic) way. Loadbalancing is done on 2 places (afaik) - by the client using the discovery.xml and a UserManagerPolicy, but also by the server itself if it forces the client to reconnect to another server than the current one (this I interpret out of a statement Jeff made about load balancing). I wonder if a policy like that pointed out by emerald will come in conflict with the decisions made by the SGS server in the case that the new discovery.xml will point to just 1 server and this is unfortunately that one the SGS server wants the client not to connect to.

Ragosch

[Jeff]

SO...

As the opthers have already said.  This is all already part of the system.  The current client-side load balancing is pure stochastic but more sophisticated algorithyms are intended.

If you want to implement your own client-side load balance you basically do two things:
(1) Implement your own ujser manager that reports the specific info you want to have available for laod balancing to report manager.  This is automaticly destributed for you to instanes of the DiscoveryManager sitting on web servers who write the discovery XML file your client goes and fetches  All of this is built into the system..

(2) Then implement a UserManagerPolicy that eats that XML and uses the spcific data.

Note however that a 100% deterministic load balance is a BAD idea.  The reason is this:

Imagine a slice with 500 users  on it fails.  All of a sudden, all 500 users go looking for a new connection point.  They will all get the same XML file simultanouesly.  They then all try to connect to the least laoded serve atonce, spamming it and vastly over-loading it.

For this reason what we are looking at down the pike is a statistically weighted stochastic choice.

[emerald]

Synchronization of data is given because every mutation of the objectstore is done in a transactional (atomic) way.

i do understands that SGS provides data syn. hmm, if all the servers are accessing one central DB, i guess i dont have to worry abt data syn. but if there are more than one persistent storage, then syn is required right? this is because we're also planning to expand the game to regionally as well as globally.

Loadbalancing is done on 2 places (afaik) - by the client using the discovery.xml and a UserManagerPolicy, but also by the server itself if it forces the client to reconnect to another server than the current one (this I interpret out of a statement Jeff made about load balancing). I wonder if a policy like that pointed out by emerald will come in conflict with the decisions made by the SGS server in the case that the new discovery.xml will point to just 1 server and this is unfortunately that one the SGS server wants the client not to connect to.

thanks for bringing this issue up. i have overlooked it. i was concerned with making my client more lightweight and more transparent to load balancing. thought i could get the server to handle all the load balancing. well, in that case, i will have to adopt the suggestion above.

[Ragosch]

Emerald, I see what you are up to, but I fear you cant gain control over the ObjectStore they way you want it. There is only one ObjectStore which is accessed by all the GLEs in the cluster and access to this ObjectStore is transparent to the server application (=only the SGS backend has direct access to the ObjectStore). There is not even a fixed model how the ObjectStore is actually implemented or handled (=which database is used, it does not need to be the current one afaik).

I also wonder on which level the transactional services are provided, inside the SGS or does the SGS use database services to ensure transactional integrity - I dont believe in the last because PEEK is non-reread-safe, what is a problem because it will cause many GETs where a reread-safe PEEK would be enough on a temporary copy of the requested GLO. This copy should be made with the first access to the GLO from that task and subsequent reads should access this copy instead of a new PEEK into the ObjectStore - this could be a problem, but maybe I am wrong and this is already handled and the term "non-reread-safe" is misleading here.

Also I am curious if the ObjectStore is stored actually on the same hardware or farmed out onto the servers in the cluster - I dont believe in the last because it would be too high of a risk. But on the other hand there need to be some kind of backup otherwise a failure of the ObjectStore server woud be fatal. But maybe Jeff can tell us more about it and those management tools needed to clean up the ObjectStore from time to time (I think of kind of a garbage collection here used during sheduled downtime of the system for maintainance purposes). There is a high risk of GLOs which are no longer referenced by any other valid GLO in the ObjectStore and therefore unaccessible but still remaining in the ObjectStore - this might be caused by bugs and we need to discover and handle those things in a way.

Sorry, that I put so many issues into one post - I just reflected what I was thinking about when I read Emeralds post.

Ragosch

Games published by our own members! Check 'em out!

[Jeff]

Emerald, I see what you are up to, but I fear you cant gain control over the ObjectStore they way you want it. There is only one ObjectStore which is accessed by all the GLEs in the cluster and access to this ObjectStore is transparent to the server application (=only the SGS backend has direct access to the ObjectStore). There is not even a fixed model how the ObjectStore is actually implemented or handled (=which database is used, it does not need to be the current one afaik).

This is true that the ObjectStore is under the control of the system and not directly acessible from the coding model.  We have *talked* internally about openoing up the ObjectStore interface and making the store pluggable in order to support third party ObjectStore vendors but we havent doen that yet.

Im still not quite following the issue.  is the issue that youa re trying to synchroinize clusters on different contents so they all reflect a single view of the world?  This is a hugely difficult problem due to the latencies you will encounter going trans-continental.

I also wonder on which level the transactional services are provided, inside the SGS or does the SGS use database services to ensure transactional integrity -

Some of both, depending on the ObjectStore implementation.  From the POVof the GLE the ObjectStore provides the transactional context and is responsible for it.  However we build ontop of the databases we currently use in order to implement our deadlock avoidance scheme (Time Stamp Ordering.)

I dont believe in the last because PEEK is non-reread-safe,

Actually, if you are talking about within 1 event (which means within 1 transactional contaex) PEEK is re-read safe in that all peeks on GLO references that reference the same GLO will return a reference to tyhe same object EXCEPT in the case that a PEEK is followed by a GET.   The GET will return a new object and every PEEK after that wil lreturn the same object as the GET.  This turns out to be necessary to insure ACID properties.

a new PEEK into the ObjectStore - this could be a problem, but maybe I am wrong and this is already handled and the term "non-reread-safe" is misleading here.

Yes this is already handled.  When we say "non-repeatable read" we are referring to reads across tasks/transactions.  Within any 1 task a PEEK is a repeatable read with the caveat above.

Also I am curious if the ObjectStore is stored actually on the same hardware or farmed out onto the servers in the cluster -

Our current "big" implementation is based on  HADB which is a seperate set of servers which have their own fail-over and disaster recovery.  Having said that, we are also lookign at the moment at some intermediate layers to deal with some huge- scale scaling issues.

There is a high risk of GLOs which are no longer referenced by any other valid GLO in the ObjectStore and therefore unaccessible but still remaining in the ObjectStore - this might be caused by bugs and we need to discover and handle those things in a way.

GLOs are "real objects" ina  simualtion sense so they never tgo away unless explicitly destroyed.  ANy named object can be found without any other referemce so those need to be treated as "root" objects.  Having said this, gaving some tools to trace from the named objects to all references objects and find those no longer referenced is not a bad idea.

We're still designing all the admin tools, ill add it to the list of ideas for the team to discuss

[Ragosch]

Fine! And thank you, Jeff, for you detailed answer - I am glad to hear that PEEKs are re-read-safe in the scope of a task; this was something I was worrying about a lot because it would have been a horrifying bottleneck. Thank you for clarification, you saved my day 

Ragosch

[emerald]

Emerald, I see what you are up to, but I fear you cant gain control over the ObjectStore they way you want it. There is only one ObjectStore which is accessed by all the GLEs in the cluster and access to this ObjectStore is transparent to the server application (=only the SGS backend has direct access to the ObjectStore). There is not even a fixed model how the ObjectStore is actually implemented or handled (=which database is used, it does not need to be the current one afaik).

This is true that the ObjectStore is under the control of the system and not directly acessible from the coding model.  We have *talked* internally about openoing up the ObjectStore interface and making the store pluggable in order to support third party ObjectStore vendors but we havent doen that yet.

Im still not quite following the issue.  is the issue that youa re trying to synchroinize clusters on different contents so they all reflect a single view of the world?  This is a hugely difficult problem due to the latencies you will encounter going trans-continental.

yes. i'm trying to syn clusters on different contents so they all reflect a single view of the world.

[Jeff]

No offense, but I think you are dreaming the impossible dream on trying to synch clusters trans-continentally.

Having to comitt every transaction across continents will introduce horrible latencies if you wait for them all to complete.  Not waiting for them all to complete will break your referenitial integrity.

.  If you want players around the world to play in the same game then IMHO you are better off centralizing your server room someplace that minimizes the worst-case lag to your expected clinet base and then desigining your cleint/server protocol to support that level of latency.

(Note that in this case "cnetralizing" refers to internet topology, not necessarily geography.)

[emerald]

No offense, but I think you are dreaming the impossible dream on trying to synch clusters trans-continentally.

Having to comitt every transaction across continents will introduce horrible latencies if you wait for them all to complete.  Not waiting for them all to complete will break your referenitial integrity.

.  If you want players around the world to play in the same game then IMHO you are better off centralizing your server room someplace that minimizes the worst-case lag to your expected clinet base and then desigining your cleint/server protocol to support that level of latency.

(Note that in this case "cnetralizing" refers to internet topology, not necessarily geography.)

thank for the suggestion. no offences to me. 
in that case, it seems that, if i were to have the same game in each server, then the objectstore in each server will be individual not sharing of data? except with ur suggestion of implementation?

actually what i'm trying to do is to have multiple servers with the same game so that clients can logon to the servers to play. and i would like the players to view all other players like they belong to the same world. (do you call this cluster?)

[Ragosch]

Does this mean you want several parallel worlds on different shards (like World of Warcraft for example) and just a connection between those shards on the communication tier without sharing the worlds itself?

[emerald]

Does this mean you want several parallel worlds on different shards (like World of Warcraft for example) and just a connection between those shards on the communication tier without sharing the worlds itself?

yes. now then i remembered my boss telling me about the Grid technology which allows all the players to see it as a real world.
so sorry about the "thinking the impossible dream"..

back to Ragosch, yes, tt's what i'm trying to do, ie. World of Warcraft.

[Ragosch]

@ Emerald:

But that is one of the downsides of WoW - players are hindered to play together if they dont know each other before joining a server. Is there a reason why you want your game to be sharded into meaningless worlds where those things you do never ever have any real meaning to the majority of people, instead of providing a meaningful big one-world-solution for all players like EVE did it on their 70-server-cluster?- IMO we are interested in SGS technology because we can handle those clusters with SGS easily. Where do you see the advantage of a sharded-worlds solution over a one-world-solution?- Or to say it the other way round, why should I as a player be interested to talk to someone playing on another shard, if nothing this person will do ever has an effect on my avatar, because I am on another shard than he/she is? (besides a nice small-talk, I mean) 

Ragosch

[Ragosch]

On possible solution to have several parallel worlds where all players can communicate with each other over a common channel could be like that:

you install your game under several names in the SGS; each "game" is a separate parallel world. Now you have a special "client" program which logs in to all those games and broadcasts the input of the common channel to all the other games. This way a common channel can be used from all the worlds to speak with users from other worlds. But users cannot open private channels cross-world that easily like in a single world.

Ragosch

[abies]

But that is one of the downsides of WoW - players are hindered to play together if they dont know each other before joining a server. Is there a reason why you want your game to be sharded into meaningless worlds where those things you do never ever have any real meaning to the majority of people, instead of providing a meaningful big one-world-solution for all players like EVE did it on their 70-server-cluster?

As far as I know, technology part is smaller part of equation with shard concept. Bigger part is content - putting 2 million players into 6-city world means crowded streets... Some games try to work around that by using multi-instance cities (guildwars for example) and instanced quests/areas. But in such case, you can as well go with full blown sharded design, just allow people to jump between shards.

EVE is unique not because it can handle 25k players at once in one shard, but because it has world large enough to host these players and provide some meaningful activities. But even CCP has created separate set of servers for Chinese market - again, because of design/cultural reasons, not so much because of technology limitations.

BTW, as far as chat is concerned, I don't see a reason why chat should have anything to do with SGS. Having specialized chat server(s) is probably a better way to solve it for big scale world.

[blahblahblahh]

If you want players around the world to play in the same game then IMHO you are better off centralizing your server room someplace that minimizes the worst-case lag to your expected clinet base and then desigining your cleint/server protocol to support that level of latency.

Well, what most people do is speak to Akamai et al and get a decent managed virtual delivery network overlaid on the internet.

But you need to have hundreds of thousands of players, or tens of thousands of subscribers, before its worth the cost of such things. Its not something you should be worrying about now .

[Ragosch]

BTW, as far as chat is concerned, I don't see a reason why chat should have anything to do with SGS. Having specialized chat server(s) is probably a better way to solve it for big scale world.

But SGS provides a chat system within SGS on the communication tier, why not use it, if it is already there and managed on mixed client/server and peer-to-peer level?- I never was a friend of extern applications to do ingame chat - neither by voice (teamspeak for example) nor by text using IRC channels. The pure handling of those separate applications kills immersiveness IMO or did you think of a chat system integrated nicely into the client which is just not part of the SGS?- There you would also have to check for people allowed to join channels and such, so you will need some kind of interaction with the SGS too - so I see no real advantage for this approach instead of using the SGS chat system directly.

Ragosch

[Jeff]

I think the chat question very much depends on what your are trying to do with the chat and what the costs in time/complexity/management are for each approach.  Its soemthing each game will likely decide for itself.