Hi

Im doing a lock-step RTS using raknet. When i try my game with a friend we get constant connection problems (waiting for the other client to send command so next step can be calculated). I dont get this when running a "local multiplayer" game with me running two clients.

Locksteps are 50ms

I got 0 ping

He got 15 ping

This might be a quite wide question, but what might the problem be here? If ping is 15 shouldnt we (theoretically) be able to run it at 30 ms lockstep (two way so 15+15 = 30ms) with only occasional lag (since ping wont be 100% stable)?

Thanks
Erik

If you are testing everything on one machine you can fool yourself. Everything can be internal, not using the wires or the networking hardware, and you can fool yourself. I've run into this before testing a Java server and client on the same machine, only to find that it was way slower than I thought when finally using all the stuff in between.

If you've setup a local network and you are still having trouble, try wireshark to see if what you think is happening is really happening. These things are really hard to guess at.

Are you using TCP or some form of "reliable" UDP? Are you sure your packets are being sent when you think they are?

To clearify: I dont have any problem WHEN running local (client and server on same machine). When playing with friend in another city (over the internet) i have lag.

I guess its TCP. Just direct connecting using IP-adress.

I tried change lockstep to 100ms but still the same problem. Dont know whats going on...

In typical lockstep simulations, you will send commands for X steps into the future. This means that the commands will actually be queued, and take effect later.

If you are using TCP, are you turning on TCP_NODELAY on your sockets?

but doesnt 15 ping mean communication takes 15ms one-way? (so 30 ms both ways)

Then why do i get lag? (need to wait for his commands)

Is this the general idea? I mean there could be errors in my implementation but its hard for you guys to comment on that right now.

If TCP_NODELAY is not explicitly enabled (which is often disabled by default) your TCP implementation will not send data immediately and instead see if it can combine more data into a single packet. If that is indeed the case you are sending a packet every N frames (where N depends on your packet size and what timeout/size your TCP stack considers reasonable).

I got 0 ping
He got 15 ping

The numbers are suspicious.

What are you using for timings? How is your process being woken up when data comes in? Most timers on Windows are either 10ms or 15ms granularity depending on things. Also, that is the same frequency used by default for scheduling when processes wake up. So my guess is you are using a 15ms granularity timer, or you are not measuring as soon as data arrives.

Running ping over time you might see something like 3ms, 3ms, 4ms, 3ms, or you might see 22ms, 23ms, 22ms, 23ms.

Seeing only exact multiples of the OS timeslice frequencies means you probably aren't measuring the ping time, but are instead probably measuring the OS scheduling time.

Im using raknet.

1. I dont know how to enable TCP_NODELAY to try if that helps. Is it a windows or raknet command? How do i enable it?

2. For ping im using

peer->GetAveragePing(serverAdress);

The resolution of this function is not given in the doc.

3. If the other user indeed would have 15 ping, i should be able to run 50 ms locksteps right? Given that my implementation would be otherwise sound?

I think Raknet uses UDP, and thus doesn't need TCP_NODELAY. I missed the mention of raknet in the initial question.

Does Raknet do packet scheduling? Does it actually send packets at the same frequency as your simulation time steps?

In general, you should assume that full round-trip time will be bigger than your time step, and schedule all commands for some future tick, rather than requiring each client to get the data to you each time you take a step.