RE: [Algorithms] RE: Zen of Networked Physics

[Jon W. <hp...@mi...>]

> But seems like you were assuming that the server is continuously
> broadcasting "update packets" to all the clients at regular time
> intervals, is that the way in which the system works?

Clearly, for this to work, the server needs to, at a minimum, send 
you a packet every so often telling you what packets of yours it 
has received, so you can move forward your delta/update baseline.

> In this way you are using more bandwidth, but you are reducing 
> latencies due to a packet loss (since you detect and correct the 
> packet losses earlier). The redundancy introduced is affordable 
> since is small. Is that correct?

The redundancy is probably zero, because there is probably other 
data flowing from the server to the client. For example, the 
update information about other clients, so you can see the targets 
you shoot at :-) Any client/server protocol will include some kind 
of packet sequence number, and acknowledging the last number 
received from the other end is typically free in most protocols.

Also, if you're using UDP, you have 8 bytes of protocol overhead, 
instead of the 20 that TCP uses, so by comparision, you have a lot 
of space to construct your acknowledgement protocol in.

> And, what about the client? Is continuously sending "important moves"
> until they get acknowledged? When no "important moves" need to be

Yes.

> At the beginning I thought that the client and server were sending
> packets just when they already knew that was needed... But really they
> are sending redundant data all the time in order to reduce the latency,
> I think this is the most important thing I missed.

There needn't be redundant data from server to client.

> Another question I have about the topic is: if we suppress the server we
> still can reduce the latency by one half.... but we allow cheating of
> the clients, since they all must act like servers of the part of the
> world they own. Am I right?

Peer-to-peer is lower latency, but has security issues, and also 
uses more bandwidth for games with more than two players, yes.

> Well, we still can maintain the server authority but allow clients to
> inform to others clients early about their owned objects. The

There's a significant bandwidth cost to this, and there's also a 
connectivity problem (because client/server works through NAT, and 
client/client doesn't always, even with introducers).

> The server can allow the clients take objects ownership... allowing the
> owner client control this objects without snap while he owns them.

That's like inviting someone to cheat, but, yes, it COULD be done.
If the object is something like a toad, which doesn't affect score 
or gameplay, then it's safe to put it on the client.

Cheers,

			/ h+