Tag Info

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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 ...

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

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 ...

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 ...

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!).

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 ...

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 ...