[ODE] networking
Anselm Hook
anselm at hook.org
Wed Oct 16 12:10:02 2002
Hi,
Eric probably has the best solution (do all the dynamics on one machine);
networking physics is a bit of an oxymoron - you have high frequency
events being propagated over a sluggish pipe.
The naive scheme is to use a heartbeat to syncronize state between
machines. Presumably if all machines are always in the same state then
any new inputs delivered to all machines simultaneously will have the same
effect. This would result in unacceptable delays however. If you are 70
ms from a server then your sim is at least 140ms delayed. Humans start to
notice delay at around 20ms and ordinary inter-continental phone
conversations become difficult with >70ms delays. Modems typically incur
a 30ms delay and even tcp packet building and buffering can incur a 10ms
delay... obviously you need a carefully chosen hack.
If you look on the net there were once a number of companies that
specialized in fast networking for games (I think most of them are
bankrupt now).
One scheme that I liked was a dual simulation scheme: There were two
instances of the simulation running - one that was current and speculative
(allowing gratifying instant feedback) and the other was an authoritative
simulation that used an ordinary heartbeat but suffered from the full
latency of the network. The current simulation was periodically (once
every tenth of a second or so) re-computed forward from the correct but
temporally old simulation. So most of the time things would work, but
every so often the actors would pop around a bit. This is probably the
best possible scheme one can hope to achieve although it does put a large
load on the client machines.
Also there is quite a bit of research at Darpa and in some of the game dev
journals about various robust networking schemes.
Another scheme (Russ once mentioned) is the idea of a networked
constraint; that maintains the force interaction between objects over a
network (hmm, sounds like quantum physics). He'd have to explain that.
Here is a trivial scheme I've used for non-dynamics networking. Your
mileage may vary - it is highly inaccurate - it simply creates a
reasonably believable 'fiction' without forcing all machines to be
syncronized or forcing the load to be computed on the server. But note
that it is a hack.
1) First one designates one instance of an object as the "authoritative
instance" and the other instances of that same object (as exist on each
separate machine) as the "ghosts" or non-authoritative instances.
2) Requests to interact with any object (in state changing ways) have to
be routed to the authoritative instance. The authoritative instance then
echoes a second message indicating result states that all ghosts should
seek to be in. (A vanilla client server network like say 'Quake'
therefore is emulated by simply having all authoritative instances reside
on the server rather than on the client leaf nodes of the network. A peer
to peer network is designed by marking non-server objects as authoritative
and forcing requests to be re-routed to that instance (often involving
network traffic)).
3) It is ok for a ghost to locally speculate about what it should do when
it receives an impact - but throw away that information when more
authoritative feedback arrives. This often results in a ghost being
translated part way into another object - this inter-penetration can
however help the simulation as will be discussed below.
So for example:
Lets pretend you have p2p network of two machines and two robots. Each
machine is going to have an instance of each robot. I like to draw out
these instance graphs using a simple c like notation - in this case it
might look like this:
network {
machine1 {
robot1 {
is_authoritative { yes }
request_impact{}
}
robot2 {
is_authoritative { no }
where_is_authority { machine2:robot2 }
request_impact{}
}
}
machine2 {
robot1 {
is_authoritative { no }
where_is_authority { machine1:robot1 }
request_impact{}
}
robot2 {
is_authoritative { yes }
request_impact{}
}
}
}
Any requests to apply forces to an object get sent to the authority first
and the authority echoes out a real force to apply. A ghost is treated
like a statue; it simply doesn't move right away when you hit it.
An elaboration of this would be to allow ghosts to be simulated normally
but for the authority to transmit all authoritative state (position,
current forces) to all ghosts after each new force. This would result in
inter-penetration as ghosts were popped to new locations... but has worked
ok for me in the past. I would even propagate extremely high level events
such as "cross bridge" and allow each ghost to fulfill the event as it
wished - creating often quite different but plausibly believable fictions.
Anyway, as I said, your mileage may vary - it really depends on what
you're trying to do. If you simply can't afford to compute the simulation
twice, and if all you care about is some reasonably believable
non-diverging physics then this might be acceptable - it is certainly good
enough for most games. Today I'd probably use something more robust
myself though.
Hmmm, I wonder what a networked version of 'Juice' would be like. Robot
wars anybody? :-).
- a
On Wed, 16 Oct 2002, Eric Cha wrote:
> Pia,
>
> Your problem is a bit tricky to pin down, but here is my theory:
>
> Since you are controlling each robot separately (via different
> computers), any collisions detected by a given computer have to be
> transmitted (propagated) to the other computers. You didn't mention
> whether or not you are transmitting collision information in your
> program, but I am going to assume that you are..
>
> So, assuming you are propagating collision info properly (although in a
> peer-to-peer topology this is going to be tricky..), the other problem
> may be (depending on how your network code functions) one of "lag
> induced information negation".. What I mean is, computer "A" determines
> a collision has occurred and transmits the info to computer "B".
> However, because of lag, computer "B" transmits a new position to "A"
> before receiving the collision info from "A". The new position info
> from "B" then OVERRIDES the collision that "A" detected, and forces "A"
> to put it's representation of "B" into the new spot. Computer "B"
> finally receives the collision info, but disregards it because it
> happened at a position which is not current..
>
> This scenario assumes MANY things about your network code, so it is not
> a definite answer.
>
> A better way (for physics) to do things would be to designate one
> computer as "the physics simulator". Do the entire scene simulation on
> that computer, and then just transmit position/orientation/velocity
> updates to other computers. Of course, other computers would transmit
> user inputs (or even impulse/velocity/acceleration changes) to the
> simulator computer to control their respective robot.
>
> Don't know if that helped you or not, but that's my .02. =)
>
> Eric
>
> > -----Original Message-----
> > From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf
> > Of pia dalusong
> > Sent: Wednesday, October 16, 2002 12:43 AM
> > To: ode@q12.org
> > Subject: [ODE] networking
> >
> >
> > hello
> >
> > first of all thanks for replying.
> > I'm not using a client/server type of connection. I'm
> > using a peer to peer connection. This means that I
> > only have one program and though it may act as a
> > server at times it doesn't. The movements of the a
> > robot is calculated by the local computer and it just
> > sends a message containing the speed and orientation
> > of the mobot to the other computers. Any computer
> > sends a message to all the other computers connected
> > to the same simulation like a broadcast message.
> > I use ODE for practically everything even the
> > positioning. and yes, all the geoms and bodies are
> > created properly.
> >
> > although yes I do have problems concerning the lag.
> > and i'm still working on that. any suggestions are
> > welcome. and all the robots exist in the same space
> > and world.
> >
> > thanks
> >
> > pia
> >
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>