Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Networking & Multiplayer / Re: SGS database consistency model? on: 2006-07-05 17:49:35
Quote
Actually there are other solutions having to do with aggregtaing and migrating users around the back end according to usage patterns.

You can distribute ownership, but ownership needs to be in one place at a time. Thus, ownership can migrate to the "most likely" node to want to next GET the object.

However, distributed ownership still needs the (moral equivalent of) a transaction monitor to arbitrate ownership. No two ways about it -- anything less and you have a chance of ownership schizophrenia. And you _really_ don't want that! (Speaking as someone who solved this problem five years ago)
2  Game Development / Networking & Multiplayer / Re: SGS database consistency model? on: 2006-07-03 13:17:58
So the consistency is on a per-task basis -- specifically, a SGS execution process cannot locally cache the value of a peek between tasks, because the consistency model says that any new task (after a possibly remote commit) must return the committed value. This is nice for the object programmer, but a draw-back for someone attempting to implement a high-performance object store.

With the model, as described, then either each node cannot have caching (slow), or each node needs to participate in a global two-phase commit procedure (quite complicated).

If the rule was changed so that a task may get an older version of data unless it does a GET, then the implementation could be allowed to cache, and use a non-synchronous cache flush protocol, which would be higher performance and more robust (on the implementation side). The draw-back would be that you could get an older peek value after a newer commit -- but, really, if you're running on a different node, synchronization isn't guaranteed anyway.
3  Game Development / Networking & Multiplayer / Re: SGS database consistency model? on: 2006-06-29 15:13:52
Its a bit simpler to explain, actually.  These are the guarantees:

(1) Peeks are repetable within a task.  After the first peek subsequent peeks willr eturn the same object EXCEPT
(2) Doing a GET effectively resets the state so after a GET all subsequent peeks will return the same obejct as the GET.  If you are keepign referecnes  to the result os previous peeks though those remain the original object.

Thanks for the explanation. That doesn't, however, talk about the consistency model between different tasks.

Does a commit mean that any PEEK done physically after the commit completes will see the committed state, or can a physically later PEEK actually return data that is part of the pre-commit state? My guess is that, yes, a PEEK can actually return state that is out of date WRT the commit state of the object, and you'll have to use GET if you want to ensure you have the "latest" state.

I'm assuming that successive GETs are synchronized and serial (and, in fact, you can't GET an object at two places at physically the same time).
4  Game Development / Networking & Multiplayer / Re: Failed to start database 'persistant_store' on: 2006-06-14 08:02:35
The EA2 release, which I am currently workign on completing, has a better shutdown mechanism that wil let you shut it down without risking messing up the Object Store.

Are you saying that the object store is not ACID compliant? I got the impression that the object executions always took objects from a consistent, durable state to another consistent, durable state, and that this replicated across server nodes insofaras all write updates are either consistent and durable, or rolled back. Is this not the case? (In my experience, that's pretty much a requirement for any large back-end server, including games).
5  Game Development / Networking & Multiplayer / SGS database consistency model? on: 2006-06-14 01:54:33
Is the consistency model for the SGS globally sequenced?

Thus, if I peek object A on node X, then lock/write object A on node Y, then lock/write object A on node Z (which clearly sees the state from node Y), then attempt to peek object A on node X again, am I guaranteed to get the state as written from node Y or later, or is there a chance I could get the earlier state I already peeked?

I e, is the consistency semantic that a commit will always distribute state, even to peek/readers, or will the local node really only know that the view of state will advance when it actually locks/writes? The latter has performance benefits, but implementation pains...
6  Game Development / Networking & Multiplayer / Re: Representing geography in SGS on: 2006-04-25 23:05:33
Quote
overly simplistic "Im just gonna make the serve do everything" approaches don't succeed for any serious size with any kind of serious load.

Nothing overly simplistic ever scales :-)

You can combine server-side real-time physics, input-synchronous networking, and scalability, as long as you're prepared to add cheap compute boxes to serve the player load. You can easily simulate hundreds of physical entities on a single machine, so scalability on the back end in this regard is mostly a matter of figuring out how to spread simulations over multiple machines while still allowing interactions.

I agree that massive designs are all about the trade-offs, though. You forgot "engineering effort" and "art production" in the trade-off tuple, btw :-)
7  Game Development / Networking & Multiplayer / Re: Representing geography in SGS on: 2006-04-22 02:23:05
In an architecture like this the server is "listening" to all the movement and only speaks up to correct/stop a cheat.

I don't quite understand what the benefit is of that.

If the clients send data to each other, and a copy to the server, then the client can send different data to other clients than to the server; this may (depending on game design) lead to advantages to the client. The server wouldn't know, because the client would send unmodified packets to the server.

If the distribution to the other clients goes through the server, and the server "listens in" on this stream, then the server might as well be in the loop, and discard illegal data before it's even distributed. What would be the benefit of only broadcasting a correction after the fact, when the server is already involved in the distribution of the data?
8  Game Development / Networking & Multiplayer / Re: Multicasting on: 2006-04-22 02:15:22
I believe the original poster wanted to save on bandwidth bills, by sending a single multicast packet out from his server, and then having the routers on the Internet fan out as necessary.

No, you don't get that benefit from SGS. However, you don't get that benefit from anything else, either, because Multicast is impossible to implement in an efficient and scalable way. (This has been pretty well documented) Singlecast, however, might be moderately useful to save bandwidth near a specific server, but that's such a small savings (overall) on the Internet, that nobody's bothered to make it happen.

Internetworking is, for all intents and purposes, point-to-point. Learn to love it.
9  Game Development / Networking & Multiplayer / Re: Gotcha #1 - Broadcast doesn't get recieved locally on: 2006-04-06 23:39:09
I think as a player I would want application ping since it includes everything and can indicate a general problem.

Application ping tells you that you have a problem, that's true. But you'd probably notice anyway :-)

Network ping is more useful, in that it may help you figure out whether your problem is because of the network, or because of the application. If you're having problems, but network ping is stable, then it's likely the application.
10  Game Development / Networking & Multiplayer / Re: Gotcha #1 - Broadcast doesn't get recieved locally on: 2006-04-06 19:31:12
There is a ping bar graphic in WOW but it averages so much (I think) that it rarely changes even when there is noticable lag in chat.

"ping" means different things to different people. To some people, it's the time it takes an IP ICMP datagram to travel through the network to the other host, and be echoed back to you using interrupt-driven host primitives. This does not include host load at all, in most cases. This is a network-layer ping.

For other people (this is especially common for FPS players), "ping" seems to mean the time it takes to send a packet, get that packet processed by the server, and receive the next update based on the results of that packet. Thus, if the server is chugging, "ping times" would go up, even though the intervening network condition hasn't changed at all. This is an application-layer ping.

If chat has problems in WOW, but "ping" doesn't change, then it's not unlikely that there's a problem with the chat distribution subsystem, but the network transport is just fine, and the WOW ping meter just displays the network conditions.

Now, if you think the overloading of the word "ping" is bad, try getting players and engineers to agree on what "lag" is ... ;-)
11  Game Development / Networking & Multiplayer / Re: Gotcha #1 - Broadcast doesn't get recieved locally on: 2006-04-04 05:09:48
Hmm. I really dont see the issue.  There is no functional difference between:
synchronized {
  sendToOthers
  echoToMe
}

as

sendToAll

I don't necessarily agree. In a case where you send to all through the server, the server can make arrangements to serialize messages in a specific order between different objects. In the local case, you can't make that decision -- echoToMe will likely make you see the message much sooner than a message that "at the same time" is queued from the server. Also, you don't always have all the state on the client that you need to re-sort the messages in the same order as you'd see them from the server.

Therefore, the ability to echo things back to yourself from the server is sometimes useful.

The classic example is an input-synchronous RTS, but there are other cases where this structure makes sense, too. Of course, you can still implement that without explicit support, but it's more cumbersome than if there were support (duh :-)
12  Game Development / Networking & Multiplayer / Re: I Was Wrong about PDTImer! on: 2006-04-02 04:39:16
Warnings still apply though about ticking too often and filling up your system queue with back events.

Is there any way of monitoring the queue size? Monitoring the queue size over time, and the composition queue (i e, N tasks of type A, M tasks of type B) seem like pretty useful profiling tools, for example. You could also write a system that balanced quality (degraded resolution) under load.
13  Game Development / Networking & Multiplayer / Re: [SGS] DarkShooter on: 2006-03-31 00:16:06
Okay that I believe Cool  I suspect if you aked them yould find they are ALSo runing loosely coupeld physics on the client.  The only other way they could get the kind of motion theya re getting (ex a smooth arc in a jump) and not do that was if they were actually sending back paramteric curves to the client and I kind of doubt that.

I specifically asked them, and they run the same physics on the server and on the client, to avoid position cheating. Because they run physics at 30 frames per second, it means that they can smooth enough arcs when you jump -- linear interpolation between successive 33ms bites wouldn't be noticeably different from an actual parametric arc.

Thanks for clarifying the general model for the SGS back-end, too; it helps.

Last, @dsellars: I believe Jeff is suggesting that the server checks the moves the client's made using rays or swepth spheres, covering the movement area, rather than just move the object and test for intersection. Thus, the server would be running different code than the client (or at least, the same code with vastly different parameters). This is a model you can use if your game is only loosely physical, or only physical on the client (like an MMORPG).
14  Game Development / Networking & Multiplayer / Re: [SGS] DarkShooter on: 2006-03-30 23:10:35
Such architectures typically come from game programmers trying to programs ervers the same way they knwo how to program clients and its fundementally wrong.  A well done server shoudl be as event/transaction driven as possible.  Now sometiem heartbeats are inevitable but if your designing you entire game around trying to make heart-beats match rendering frames your defintiely starting  on the wrong foot.

Such architectures are also necessary for various distributed simulation systems (such as used in military wargaming, etc). Thus, I think it's fairer to say that running physics on servers makes sense for highly physical games where you want to make authoritative decisions based on physics state, but does not make sense for a typical MMORPG.

Can I read from this that you believe that SGS is not a viable technology for systems that look more like a military simulation, and less like an MMORPG?

Btw, when it comes to Cryptic: please ask them! Last I did, they said that they run physics at 30 fps on the server, and they send only controller inputs from the client. They RLE encode the last X seconds of input into each upstream packet, which will compensate for a fair bit of packet loss. I probably used the word "lockstep" wrong, as it's not an RTS model; instead, let's call it "input communication model" (as opposed to "state communication model"). I would assume that they send baseline state information every once in a while to get a client back in sync if there's been too much packet loss, or the server and client have de-synced; this would account for corrections/warping.

Last: if it takes "sub millisecond" for each get(), how can I simulate hundreds of close interacting objects in a physical simulation with 30 steps a second, per processing node? There's only 30 milliseconds per step, at that rate.

I actually have a specific kind of system in mind when I'm asking these questions -- is there another way of contacting you for more in-depth questions?
15  Game Development / Networking & Multiplayer / Re: [SGS] DarkShooter on: 2006-03-30 18:21:30
Quote
If you have a hard reference to the contrary please present it.

I've talked to Cryptic; I know some people who work there. They send user input from the client to the server (at least they did a year back), and simulate on the server. This amounts to lock-step per object. I don't think they use lock-step for the entire world. Other simulations actually use lock-step for the entire world (like www.there.com).

When you say that "no server keeps data resident," that's the conceptual model, right? In reality, the object store would not perform very well unless it could keep committed data resident on the "most probable" node for the next get, and only migrate the ownership of the state if the next get comes from somewhere else. Thus, locality in successive get-s is important for good performance. Even if you have a large, expensive NUMA machine, local memory is faster than ownership transfer.

Now, when it comes to walk meshes, well-performing collission detection data takes a little while to demarshal when you load it. You certainly don't want to do that each time you want to run another task on an object that references the mesh. Thus, assuming the objects stay alive between tasks, as long as they don't have to migrate, then that's what I meant by "keeping objects resident".

Now, consider the case where you're simulating something big -- the Earth, say. Clearly, you can't fit all the walk meshes of the Earth into RAM on a single node. Similarly, if you have a lot of entities that are distributed over this simulation, if you use stochastic distribution of entities across nodes, you will get a worst-case reference pattern: each node needs to load walk meshes (and other world date) for large parts of the simulated Earth. There is no way that such a distribution would perform well. Thus, proper load balancing MUST take locality of reference into account, such that things in New York City tend towards one node, and things in Kuala Lumpur tend towards another node, because the amount of duplicated or transferred objects between nodes goes down a lot, which means performance goes up a lot.

However, I see no way for objects to hint what localities of reference may matter. I also see no posts claiming that you can derive these localities automatically in a way that's actually sufficient to solve the problem -- but perhaps you can. You don't need to go into details about how it works, but if this problem is "solved" it'd be interesting to hear that it is; if it's not solved, then that'd be important to know, too.
16  Game Development / Networking & Multiplayer / Re: [SGS] Darkstar and physics simulation on: 2006-03-30 18:07:27
@Jeff: I suppose it could be implemented with peek if the peek-er looked at both "previous" and "current" states and took whichever was for the timestep they could read.

@mudman: The order of commit doesn't matter if you make a partial ordering rule: all objects commit for step N before any object is allowed to commit for step N+1. This is basic simulation time management; you can read (for example) the HLA standard (ISO 1516) to learn all about it.

So, assuming that all you have is peek and get, and assuming that a peek that runs in parallel with someone else's get will succeed (and return the previous state, until global commit), then the loop might look something like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
// stepped by someone who knows how to step everything in order
object::evolve(long fromStep) {
  assert( cur.time == fromStep );
  swap( prev, cur );
  cur.time = fromStep+1;
  foreach( other in myCell.findIntersectionsWithMe(fromStep) ) {
    state = other.peek();
    if( state.prev.time = fromStep ) useState = state.prev;
    else useState = state.cur;
    handleIntersection(useState);
  }
  calculateNewState();
}
// commit here

17  Game Development / Networking & Multiplayer / Re: [SGS] DarkShooter on: 2006-03-30 02:36:11
Quote
In general, for responsiveness reasons, my sugegstion on any action game is to do local collision/physics and server side sanity checking for cheating.  This allows you to decouple the server side response from your game response and get better local responsiveness.

It also allows for client cheating. If you want cheat-less physics-based games, you have to run physics on the server side. If you want non-physics-based games (like EverQuest or WOW), you can make them cheat-less without full server-side physics.

The non-determinism in simulation means that a lockstep communications model (as used in some physical MMOs like City of Heroes and in RTS-es like Warcraft III and Age of Empires) won't actually be possible. This means that you can't really fit a large world on a narrowband channel. What is the current thought about this limitation?

When it comes to scalability, keeping the entire collision mesh for the entire world on every physical server would be un-wise. You want objects that collide with a certain part of the world to be run on servers that keep that part of the world resident. Is there enough automatic object migration to make this happen? Can you talk about how objects will move between physical server processes, and what determines when this happens?
18  Game Development / Networking & Multiplayer / Re: [SGS] Darkstar and physics simulation on: 2006-03-30 02:25:06
Quote
Actually developing the destributed processing algorithym though I have a feeling is an un-done research project.  Anyone looking for a good thesis subject?  Cool

Actually, I've seen that done, although in C++. I believe one rule has to be that an object can only derive its state from the state of objects in the past (i e, you must forego the big-LCP-solver approach), and thus you will need to at least double-buffer your physics state based on time. Thus, when updating state from (step-1) to (step), everyone could get state for (step-1) without interfering, and the object could lock itself at (step). However, I don't quite see how to express this in SGS parlance, because you lock the entire object when you get() it, and there's no "commit and swap" primitive. Any ideas?

Disclaimer: Daytime, I work for a company that has significant investment in a similar area.
19  Game Development / Networking & Multiplayer / Re: [SGS] Darkstar and physics simulation on: 2006-03-28 21:54:14
You're right, the claims in the server programming manual only say "an efficient, scalable, reliable, and fault-tolerant architecture" and doesn't actually mention "secure." When you trust the client on simulation, there are a whole class of cheat-proofing you just can't do, which you can with authenticated server-side physics. For a typical RPG, it probably doesn't matter, but for something like a first-person shooter, it would.

I agree that a single object store seems like the main bottleneck. Again, for an RPG, it probably won't matter, but for something with high-action, I don't see how they could do thousands of players in a single action game world.

Does anyone know what the actual object store back-end is, and more importantly, how well it scales (in commits per second)?
20  Game Development / Networking & Multiplayer / [SGS] Darkstar and physics simulation on: 2006-03-28 19:41:00
I've been reading the Darkstar documentation. It appears to use a common transactional model, where transactions are intended to cover only a small number of objects.

However, most physics solvers available today actually throw all world objects into a big matrix, runs an LCP solver on that matrix, and out comes the new positions/velocities/orientations of the objects.

A naive implementation of this mechanism as GLOs would have a world stepper that acquires (using get()) all the objects, throw them into the solver, writes the output to the objects, and then commits. This wouldn't scale all that well. While you can partition the solver into separate "islands" that can be solved separately, knowing which island an object belongs to is part of the collision and interaction connectivity graph, which in turn would be a single large object with references to everything.

Is there a better solution to this problem within the SGS?

Also, modern physics games step at between 30 and 100 steps per second; would the object store keep up with committing the entire world at that rate? Does it do write combining, and if so, is the write combining ordered per object or store-wide?
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

ctomni231 (37 views)
2014-07-18 06:55:21

Zero Volt (35 views)
2014-07-17 23:47:54

danieldean (28 views)
2014-07-17 23:41:23

MustardPeter (31 views)
2014-07-16 23:30:00

Cero (46 views)
2014-07-16 00:42:17

Riven (47 views)
2014-07-14 18:02:53

OpenGLShaders (36 views)
2014-07-14 16:23:47

Riven (36 views)
2014-07-14 11:51:35

quew8 (32 views)
2014-07-13 13:57:52

SHC (69 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!