Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
I've read the in a LAN the data is transmitted in packets so as to allow only one station to transmit at a given time, so how could this be applied in video games LAN parties if only one device is going to transmit at a given time ?
Data are usually transmitted in packets. Because the medium is shared, only one station at a time can transmit a packet.
Stalling, Data and Computer Communications, 5th ed.Pearson
Only one device is allowed to transmit at any given time. At any other given time, another device is allowed to transmit.
How can you have a conversation at a dinner table if only person can speak at any time?
Some LAN protocols, on some media, are half duplex. That means that only one host on a LAN can send a frame at any given time. The classic example of this is the original ethernet, but the modern example is Wi-Fi.
The original ethernet ran on coax, and it used CSMA/CD (Carrier Sense Multiple Access with Collision Detection) to detect collisions where two hosts were sending at the same time, and it would then send a jamming signal because the data were corrupt. Each host would back off a random time and try to resend, but hosts first listened to the medium to see if any other host was sending.
Today, Wi-Fi uses a shared medium: the airwaves. Only one host at a time can send. Wi-Fi uses CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) to try to avoid collisions.
In human terms, each frame used on the medium is fairly small, and it doesn't stay on the medium very long, so by taking turns and sharing the medium, the hosts appear, to us slow humans, to simultaneously using the medium.
The (naive) answer is, or rather used to be, simple: It tranlates to each sender having to wait a tiny fraction of a second. There is no way around this because that's how the network works at a physical level, but it is also not very much of a problem since we're talking about a few microseconds (micro, not milli).
The somewhat less naive answer would be that unless LAN also includes WLAN, your quote is outdated (wrong). On a WLAN, you still do not have many options. While one station is sending, no other station can send (unless they use a completely different non-overlapping channel, but that's really two networks, not one, so one would be cheating).
Computers in a modern "gaming" LAN will typically be connected via at least 100BASE-TX, more likely 1000BASE-T, both of which support full-duplex operation to begin with. This means you can send and receive on the same physical cable (well, a different wire within the cable, but still) at the same time. The notion of having to wait while the cable is busy is therefore not so clean-cut any more, since sending doesn't really interfere with receiving any more. Only the traffic coming from multiple other senders independently interferes.
Further, the cables will nowadays almost without exception be plugged into a switch (rather than a hub) which can, in principle (depending on the quality of the hardware) send and receive independently on every port at the same time, and which in principle (again, depending on the quality of the hardware) has enough internal bandwidth to process N times the maximum theoretical throughput for N ports. Your mileage may vary slightly since switch quality varies. Some very cheap switches will have N ports but only enough bandwidth corresponding to half as much data as can be pushed through N ports at the same time. Often, even that is (surprisingly) perfectly good enough.
Thus, you will still have some occasional, inevitable delays due to packets having to be queued when two computers in the network send at almost-the-same time to the same destination (the switch then makes that decision, not your computer's network card), but for the most part it will "just work". Note that even when it doesn't "just work", it works anyway, only just it takes a microsecond or two longer for the data to be received.
That book is a bit dated, check out some information on how Ethernet evolved and the difference between half-duplex and full duplex:
This is true of oldschool ethernet implementations (10base2, 10base5 et al ... as well as 10baseT and 100baseT IF a non-switching hub was used) that actually used a physically or logically shared medium (cabling plant) to connect more than two transmission capable ports. If two stations accidentally transmitted at the same time, the signal on that shared medium became garbled - network ports were designed to detect such garbled signals and send yet another signal onto the medium, that could still be read correctly over the garbled data and signalled everyone that all their transmissions are invalid and will have to be repeated after a backoff time. The problem with these setups was that if anything loaded the network to its limit with small packets, the achievable bandwidth ended up significantly below the theoretical maximum, since bandwidth got wasted resolving collisions instead of transmitting data.
In a fully-switched Ethernet (as you would get when building it with any parts commonly available in a store after ca. 2004. "Fully switched" because hybrid forms exist(ed) where mutiple shared media (with more than 2 ports) were separated by switches), there are always two ports (one is on the switch, the other on a computer or other connected device) sharing a medium. Any "T" type ethernet has separate wire pairs for each direction, so between two ports it will always be possible for both of them to transmit and receive at the same time. A switch will always order packets from multiple senders into one valid sequence and transmit it wherever it decides it needs to send them, unless it is actually overloaded (which is unlikely to occur in a home network situation).
For completeness, certain other (nowadays rarely used) non-Ethernet wired LAN systems (eg Token Ring, FDDI) used different methods to discipline medium access, in some cases positively negotiating the privilege to send before anyone got to transmit a payload.
WIFI also has to deal with a shared medium problem, and also the fact that two conflicting transmitters might have different visibility to different receivers. An algorithm called CSMA/CA is used to resolve this.
On a 10Mb/s network a full-sized packet takes about 1ms to transmit. Most game packets are much smaller, so no you don't notice this latency and could get hundreds of updates per second pretty easily. The big lag comes from distance at least 18ms per 1000 mi. This is the sppeed of light and can't be avoided. Other packets on the wire can add to that latency - that's called jitter.
In every video game there is always lag between the time a player offers input (pushing a button, moving a joystick, etc.) and the reaction to that. There's even a perceptible delay between the computer sensing a control change and that change appearing in the next frame on the screen*, which is why some gamers will reduce graphics settings (making the game less pretty) to maintain 60 FPS.
Networks will introduce this lag, too, for various reasons, one of which is because players can't receive two messages at the same time. If two other computers try to send a message at the same time either one will back off and let the other go first (on a shared transmission medium, such as WiFi) or a switch will receive both at the same time but send one before the other to the destination (modern wired Ethernet).
The delays on a LAN are small, however, and are dwarfed by the amount of delay (tens or even hundreds of times greater) produced by playing over the Internet.
So how can that that work? Typically games will model the other player, predicting future motion based on current motion, so that you see him moving smoothly in a certain direction even if your computer is not always getting immediate updates about where he really is. (The code that does this is often referred to as netcode.) This is why players will sometimes suddenly jump from one place to another; the prediction got out of sync with what really was happening, often due to a network delay.
*This isn't usually perceived as, "I saw a delay" but "the controls feel sluggish" or similar.
