Hot answers tagged

9

The IP protocol, atop which TCP and UDP are constructed, specifies that datagrams are neither guaranteed to arrive in order, nor via the same route, nor, for that matter, at all (thanks Trevor for the reminder). So, irrespective of whether TCP or UDP is used, latency will fluctuate. Latency is partly due to distance travelled, which changes if the path ...


7

When serializing data, it's best not to rely on special characters for data separation. Instead, simply let the receiver know how much they need to read to complete the data. Like: PacketID [ByteLengthOfNextVariable NextVariableBytes] Then the receiver knows how much of the packet to read before moving on to the next variable. Ideally, you'd have some ...


5

This is probably not game development question, but yes. In normal IP connection, each packets may go through different intermediary "hops", and each different "hops" may have different latency. If you're using TCP to transfer your data, the protocol abstracts that for you and will reorder packets to deliver the packets in the order they were originally ...


5

For example, let's say it's tick 1000 and player 1 sends a message saying that he is going to start attacking player 2 at tick 1002. That's not how it works. What is sent is what player 1's controls do. Click on location, drag to here, pressed key X, whatever. You don't send specific game state like "is attacking". The idea being that, as long as ...


4

I found the following comment on an article on lockstep, that should explain it http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/ StarCraft don’t use peer-to-peer it uses client-server model with lockstep (at least warcraft 3 does so). It has the advantage what theoreticaly laggers ...


4

The choice to make depends on what your multiplayer architecture is for the game. There are two major architectures for multiplayer games, the first being client based, in which each client is responsible for its own decision making and updating, and the server simply distributes these updates to other players. The other is an authoritative server, and ...


2

Absolutely everything about an IP network can change at any time. The following article discusses how things like latency, packet loss, and throughput can vary and why: DEI Tech Note 0021: Loss, Latency, and Speed


2

There are any number of ways to do this. You could, for example, treat || as being a literal | and not your field separator. If your current process for decoding your packet involves first splitting it on single | tokens, you'll probably want to either change the split so it uses a regular expression with a negative lookahead to avoid the || or process the ...


2

If your system can deserialize the data on the other end regardless of the field order, you don't need to enforce that order. But you probably want to anyway, because it's better. If you have any dependency on that ordering (as in, you enumerate the results of getFields() on the receiving end and deserialize each field in succession), you had best make sure ...


1

Unfortunately, there is a flaw in what you're suggesting. If ClientA starts the session, does stuff, then gets disconnected for any reason, then ClientB joins the session, who's going to send the stack to ClientB? You should store the stack on the server and send it to the clients as they join. This will have also the advantage of preventing around with ...


1

None of the options you listed is really a good choice. Nagling is turned off by default so each packet you send will be an individual packet. A good rule in game networking is to find a send rate and don't go over that. That is perform your own nagling of packets. Essentially don't send 30 individual packets one after another for individual points. (You'd ...


1

I would suggest making a separate buffer for each player that is responsible for squashing commands together. Basically, it should reduce a set of network packets into an approximation of user's input, which is sampled only once per game update that should result in equally significant change for every player. The question is, what should be sampled from ...


1

Your game shouldn't depend on the speed at which the packets are sent as it will vary depending on your internet connection regardless of what rate you attempt to send them. Instead your server should move the character depending on the user actions (e.g. while they are pressing (sending) W move them forward, or if you are counting mouse clicks then send ...


1

Client -> Awaiting Gamestate Server -> sending Gamestate to Client Server -> Setting Position and Whatever ( depends how you divide the tasks for Client-Server-Model) -> sending to Client Client -> Sends Player movement to server Server -> Sends Playermovement to other players another point: You cannot keep everything synchronous , games often use ...


1

Because TCP buffers data at both the client (prior to sending a packet) and the remote host (remote host might not be notified a packet was received until several packets are received and combined together into a data buffer). See my article why TCP is unsuitable for games. You hear it said, but you don't believe it until you try it (or until a major game ...


1

While UDP is bad at emulating TCP's feature-set as a whole, you could still see a potential performance benefit from picking and choosing features for different kinds of packets, e.g., one might choose to use UDP for voice chat functionality (where we really don't need things to stay in perfect lock-step anyway) and TCP for actual gameplay. Further, we could ...


1

Aside from what's already been said, don't forget that routers are allowed to arbitrarily drop packets, meaning in TCP a packet could theoretically take arbitrarily long to reach its destination (and in UDP, it might never reach its destination!).



Only top voted, non community-wiki answers of a minimum length are eligible