• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Max Power

Latency and server/client-time

12 posts in this topic

Hi,

 

I am working on a UDP client/server setup with boost::asio at the moment. I've got some basic ack&reliability system in place and tested a connection over the internet yesterday for the first time (instead of running on ports on the same machine...). There's only chat, sending of input and syncing of a constant number of game objects so far.

 

Against my expectations, everything is working pretty nicely already. Latency was around 120 ms. I guess that's ok, given I'm not running an actual server, just two ordinary PCs. I just check on the local machine, how long it takes until I get an (immediate) reply for a sent packet.

 

Now I'm wondering if there's a way to split this ping into send/receive-travel times. I mean most of the time, I want to know how old a packet is that was sent one-way, like a server-snapshot/update.

 

I could just compare simulation times for that, if they are running synchronously. But the way I see it, the only way to sync timers on two machines is by knowing how long a message is underway in ONE direction.

 

Any advice?

0

Share this post


Link to post
Share on other sites

The best you might be able to do is keep track of the differences in time  Send your 'ping' msg (with your departure clock time) and have the other side mark it with its departure time and when it arrives add the packets return incoming time (with your local clock ).

 

You can then tell when the roundtrip and each half varies (by doing various dif calculations with the) to see if they get longer or shorter  (if not the exact time they took).    The clock values (perfromance timer times) pasted from either side should remain fairly releative to each other at least.

 

Each leg of the round trip can be figured  for their changing time (from other packets times) once the relative clock values are known.

1

Share this post


Link to post
Share on other sites

Why are you doing that? In practice there is so much noise it is very rarely used. To synchronize machines requires many measurements done over time.

 

 

Games generally use relative time from the moment they start, as observed by whoever is in control. The server says this is simulation step 2143, or that you are 34213ms into the game, and that's the end of it. They might use the round trip time estimates and use half of it for the approximation, but trying to determine the exact per-direction latency at any time is a more challenging problem.

 

Latency is constantly changing. Some other process opens an Internet connection and you are fighting over bandwidth. Or the neighbor starts a file download and your upstream connection deprioritizes your traffic very slightly for a while. Few games need more precision than you can find with the round trip time.

1

Share this post


Link to post
Share on other sites
If the only information you have available is time sent and time received according to an unsynchronized clock on either end, then no, you cannot really split the round-trip time into a "send" and a "receive" part.

However, that doesn't actually matter. What you want to know is "how early should I send commands so that they are at the server at server time T," and "When I receive the state of an object stamped at time T, what time should I display it at?" Both of these questions can be answered with relative measurements, rather than trying to absolutely pin down the server/client send/receive latency. And both of those answers typically include some amount of latency compensation (de-jitter buffer) that make an absolute measurement less useful anyway.
1

Share this post


Link to post
Share on other sites

If the only information you have available is time sent and time received according to an unsynchronized clock on either end, then no, you cannot really split the round-trip time into a "send" and a "receive" part.

However, that doesn't actually matter. What you want to know is "how early should I send commands so that they are at the server at server time T," and "When I receive the state of an object stamped at time T, what time should I display it at?" Both of these questions can be answered with relative measurements, rather than trying to absolutely pin down the server/client send/receive latency. And both of those answers typically include some amount of latency compensation (de-jitter buffer) that make an absolute measurement less useful anyway.

 

 

You have the time difference from both sides (and the history from previous transmissions of the same time data)

 

The clocks might be unsynchronized between each other but arent they usually each consistant to itself (and thus relatively consistant in difference to ecah other clock...)?

 

So you keep history of the data    his send time versus my recieve time   and compare that difference to the next send done (and so on)

You can build a statistical model of typical transit time  (and both sides can do this)  AND you can communicate the result to the other side of the connection (and the difference of that (the ratio of diference of differences) .can tell you more).

 

The change in send time can be valuable (by magnitude at least)  as when things go downhill they go very downhill (and its time for some throttling or other compensation) and you can judge roughly averages to see how much variation the transmission times are to do some adaption stategies.

1

Share this post


Link to post
Share on other sites
The only data you need to keep (and communicate) is whether the data made it too late, much too early, or about right. If the data made it too late, tell the client to send it sooner (you can say by how much.) If the data made it much too early, tell the client to send it later (by about half of the difference.) And, when the data arrives within some target window (say, between 0 and 100 ms before it's needed,) then you tell the client it's doing OK.
2

Share this post


Link to post
Share on other sites

Sorry for not replying, but I have been working on the UDP-connection code the whole week. After many hours of frustrating debugging I can finally guarantee 100% reliability for packets that are flagged as "essential" to come through, and for packets that are marked "sequence_critical" to come through and be processed before any other packet that isn't flagged "sequence_independent", even if individual packets or the whole data-exchange is completely lost in one or both directions for any duration. Yay! That just off-topic...

 

Now I guess I won't really know wether I need synced timers or not until I understand game-syncing and lag-compensation techniques...

0

Share this post


Link to post
Share on other sites

I can finally guarantee 100% reliability for packets that are flagged as "essential" to come through


Really? What if I take a pair of scissors to your Ethernet cable?
0

Share this post


Link to post
Share on other sites

Damn, I knew I had overlooked something!

 

//TODO: get scissor-proof ethernet cables or train ferrets to fight off scissor-wielding intruders

0

Share this post


Link to post
Share on other sites
And, more practically: You cannot be 100% certain. Your API/library needs to expose the possibility of failure to the client. Pretending that re-trying will always work is not going to work, and the client is likely more able to make the right determination of what to do than your library is, because it has more information.
0

Share this post


Link to post
Share on other sites

And, more practically: You cannot be 100% certain. Your API/library needs to expose the possibility of failure to the client. Pretending that re-trying will always work is not going to work, and the client is likely more able to make the right determination of what to do than your library is, because it has more information.

 

 

I previously have used UDP, building from the ground up to include features like that along with the reliable delivery mechanism (session security, timing statistics, connection keep-alives in lieu of traffic, lower priority file xfers, App level throttling notifications, thread/process friendly minimal-locking features, msg-aggregation/ connection-postboxing, connection disruption notifications, etc...)  All integrated within the Networking thread for efficiency    (example is : connection timing statistic ping/reply being handled directly to cut out app level delays and maintaining the statistics a higher App level would make use of).    Reinventing the wheel I suppose, but I was attempting to squeeze out as much capacity/efficiency for a application that did alot of inter-server traffic.

0

Share this post


Link to post
Share on other sites

Well...

 

I have callback function pointers inside my connection-manager class for the user to set. Like onConnect, onTimeout and stuff like that. I know it's very basic, but I'm hopeful it'll suit my needs ^^. If not, I will expand it along the way. It's definitely something to get started with. I've got lots of graphical, physical, audio and game-related things to take care of as well... and now with networking in mind, I'm gonna have to restructure the whole thing more or less completely, I guess.

0

Share this post


Link to post
Share on other sites

Well...

 

I have callback function pointers inside my connection-manager class for the user to set. Like onConnect, onTimeout and stuff like that. I know it's very basic, but I'm hopeful it'll suit my needs ^^. If not, I will expand it along the way. It's definitely something to get started with. I've got lots of graphical, physical, audio and game-related things to take care of as well... and now with networking in mind, I'm gonna have to restructure the whole thing more or less completely, I guess.

 

 

A big 'gaaaah!!'  is optimizing for multiple cores  (lock issues) where you have only one Network thread (with Affinity)  that then all the higher level App threads work through it  (again for high performance needs that might not exist for less stressed game mechanics).     

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0