well, the server creates a game session and the client connects to the server's ip/port. that's all. anyway, it seems like i'm using the wrong terminology ...
Yup, you're using a client/server model then.
About extrapolation: It was originally designed (for the millitary simulation environement DIS) to cut down on the bandwidth required to send updates. What happens is that for each extrapolated object all peers run the same extrapolation algorithm. When the peer that is the owner of the object notices that fx the extrapolated pos for the object exceeds some threshold, it sends an update again. That way you wouldn't need to keep sending updates blindly.
yes, but the directions of the cars might change all the time. i don't think this would be a good approach.
Well it depends on the type of race game; the cars motion might have pretty steady derivates if its somewhat realistic. Unless you're creating somekind of arcade race game where you have very swift & unrealistic steering for example. With steady derivates, latencies up to 100ms - 150ms should be ok. You could check out turbosliders (google on it) to see a nice example, it works really well even at relatively high pings. it predicts (extrapolates) up to 150ms or something, it sets this prediction value according to the latency. For a car game you could even have an A.I. algorithm help you predict the motion of the car, as cars most probably try to stay on the track for example.
my framerate is 30fps and i'm sending one packet every frame (33 ms).
Note that you should never limit your framerate to sync the network or gamelogic, ever!
Instead run your logic at a fixed rate, fx 60hz and draw as many frames as possible in the cpu time left. (http://www.gaffer.org/articles/Timestep.html
Also dont send out a network update each frame, this is what doom did in the early days, it could hog up entire networks back then
Though 30 updates/sec might not be that bad of a sampling rate for a racing game. Just check whether a certain sampling time has been exceeded in your gameloop, if so, assemble an update.
Bruno wrote: my opinion is that the key is not to try to have the fastest network by using udp (i recomend you to use tcp and standard client/server ) or other low-level optimisation but rather to delay player action
Well, for internet play i'd advice to use udp (at least for fast non reliable updates like car pos etc). TCP tends to be less suited for such updates (reliable delivery causes delay with latency spikes while youre not interested in old pos data), but there plenty of discussions about that topic on in the networking section.
Bruno wrote: what i mean is that if i turn left my car : a packet should be immediatly send to the server but this order will be take in consideration client side (and server side) only 100/200ms later so when the car will start to turn left client side server will already know(already receive packet) and both will be synchronized. all client should play in past to enable server to know the futur. the delay you introduce to client side(about 100/200 ms) will not be visible.
Yup, thats a very good way to snoop off some of the message delay. There's a good research paper on that subject with its focus on racing games:http://portal.acm.org/citation.cfm?id=507674&dl=GUIDE&coll=GUIDEhttp://portal.acm.org/citation.cfm?id=566512&dl=ACM&coll=portal
*there should be free versions of these papers around (ACM requires an account)
how do cubic splines work? (tell me only if it's easy to explain, if not i'll google a bit ...)http://www.gamedev.net/reference/articles/article914.asp
but anyway, even if i can do perfect extrapolation there will still be stuttering if the network latency is too big. i wonder how professional games deal with that. i've seen games where many people play against each other over the (slow) internet and the movements are still very smooth. with my game i even have problems in a (relatively fast) intranet.
Well with the techniques outlined in these posts you should be able to make it run smooth. Ofcourse with latencies >300ms or so it becomes almost impossible to have both a consistent and a realtime display. With multiplayer games theres always a tradeoff between consistency /real-time / scalability
I had a nice chat with the developer of turbosliders once. I could dig up some old email conversations and outline some of the techniques he used if you're interested...