So the server is lagging a bit at the moment. Sounds like a good time to talk about general lag issues.
Here's what I know about the way WC2 and battle.net worked 15 years ago... we're now using a PvPGN server and an AH server also, so things could be different now. If I'm wrong about any of this stuff, please reply and add your info.... but AFAIK it's like this:
First there's 2 types of network traffic you need to know about:
(don't worry it's really not that technical...) UDP:
User Datagram Protocol
Transmission Control Protocol
The difference is this:
makes a connection between 2 computers, in this case a player's computer and the server. Once a TCP
connection has been made, the TCP
protocol guarantees that every message either of them sends to the other is successful. It checks, and if there's a problem, the message is sent again, until it goes through, or eventually the connection is abandoned, whereupon both ends will be notified that the connection has failed.
On the other hand..
does not do this at all. If one computer sends a UDP
packet to another, it has no idea if the other computer receives it or not. Some program running on the other computer can send back a message confirming the packet arrived, if it wants, but that is not part of the UDP
protocol (whereas it is built into TCP
There's also another 2 terms I'm going to use a bit which are: IPX:
Internetwork Packet Exchange
is just an old network protocol that is no longer used. Although internally different, as far as the descriptions above go, IPX
can be considered the same as UDP
. It was popular in the late 80's and early 90's but by '96 it was on the way out and was not widely supported after that.
is the basis of the internet. It's that base layer that is sending packets from one "IP Address" to another. You have probably heard the term "TCP/IP" before, well this is the "IP" part. By this terminology the UDP
traffic could be called "UDP/IP" because the "IP" protocol is operating beneath both of them. Often these days people say "IP" when referring to an IP Address
, however here I'm talking about the protocol itself. When I'm talking about an IP address
I say "address".
So... going back to 1996 and Warcraft II:Tides of Darkness
when the internet was still in it's infancy, the guys at Blizzard used a network protocol they were familiar with to implement the pre-battle.net multiplayer games. That was IPX
. For those of you old enough to remember Kali
this is where that fits in. Kali is an IPX
emulator, so it allowed people to play multiplayer games based on the old IPX
protocol on that new wonder of the modern age "The Internet!".
But the point is this: the networking side of the game engine has remained pretty much unchanged from 1996. When Blizzard released Warcraft II:Battle.net Edition
in 1999, they included all sorts of cool new stuff related to battle.net: server channels, messaging, friend lists etc.., and of course the most important thing - the ability to make a game or join a game. All these battle.net features worked over a TCP
connection. This connection is established when you logon to battle.net and (being TCP
) it maintains itself, and guarantees the integrity of all messages passed through it.... for example unless the connection fails and one of you is actually dis-connected from the server, a /m to another player NEVER fails, even with bad lag it will still go through eventually.
If you make a game, your client (wc2 program) will talk to the server over this TCP
connection and tell it the name of your game and other details. If click the JOIN button the server will talk to your client over this TCP
connection and give it a list of games. This list includes the game name, the pud, the settings, and most importantly the IP address
of the host.
It is at THIS point in the process that battle.net ceases to be part of the equation. When you join a game, the internals, for the most part are still exactly the same as they were in 1996, the only difference is that instead of using the old IPX protocol, which was not supported by the internet, BNE substituted the UDP protocol, which was supported. This, however is just wrapping your sandwich in cling-wrap instead of tin-foil, its still a BLT inside. When you join a game (or try to!) you start sending peer-to-peer UPD packets the host's client, which then sends you a list of addresses for the other clients already in the game, and sends your address to them. To successfully join your client needs to make UPD "connections" to all of the other clients in the game.
I say "connections" in quotes, because of course UDP
(or IPX) does not make connections it just blindly sends packets and hopes they arrive. Your client (the wc2 program) IS, of course keeping track of what packets arrive, and if one connection is losing packets you will see it on the lag screen, or as we know if YOU are the person with the bad connection you will often see several or all of the other players listed on the lag screen, because from your client's point of view packets are missing from lots of other clients.
So this is how WC2 games work over a network, with all of the clients all firing UDP
packets at each other. So what about the server? Well you trusty TCP connection to the server remains in place, but this connection does not have anything to do with the game
. It can't cause game lag. The only thing that can cause game lag is problems with the UDP traffic between the clients
The BNE client knows to send any chat that starts with a "/" to the server over this TCP connection and the server will then process that message or reply with a WTF? and your client will say "Unknown Command". If the server is lagging it can take 5 or even 10 seconds to get a response. Can you imagine if it took 5 or 10 seconds for every update in the game? There's just no way.... that would be beyond bad lag. Generally speaking for a game not to have annoying lag, the clients needs to update each other every 1 second or so, ideally much less. That means every client needs to be able to send and receive a UPD packet to/from every other client no later than once a second.
BUT, the clients do not, as part of the game send any UPD packets to or receive any UDP
packets from the server. The only time this happens is when you first login to the server, it does a check to see if you can send/receive UDP packets over port 6112. The reason this will usually succeed even though you may still be unable to host is to do with the way your networking infrastructure (modem/router/network card/drivers etc.) handles traffic. In short, once the TCP
connection is established with the server, the underlying IP
"Internet Protocol" automatically sends any traffic from the server to the client at the other end of the connection, regardless of if it is TCP, UDP or whatever.
This is how the "lat trick" works if you haven’t got your game port properly routed. You have a TCP
connection to the server, which gives you the IP
address of the host. So your client sends a UDP
packet to the host saying "I want to join", but at this point you there hasn't been any communication whatsoever between the two clients. Any channel chat or /m messaging is relayed through the server, so if the game host hasn't got the game port "opened" (properly routed to the client) then when a random UDP
packet turns up from some random client, the IP
has no idea what to do with it. But if you alternately make games, then try to join each others' games, you can train the IP
running in your hardware to associate traffic over that port with a certain IP
But if you can't get UDP
packets through to the server when you log in it will give you a warning message saying you won't be able to join games. It will, however still let you log in and chat/message/see the game list etc... everything that happens over the TCP
connection. If you join like this you will have the grey "bot" icon which has an unplugged power cord on it.
So back to joining a game. Why can you join a game even if you haven’t got your game port properly routed? Why is it just when you host? This is all IP
layer stuff, like the "lat trick" above. The problem is with that very first "I want to join" message that your client sends to the game host. If the host's game port isn't routed to the correct end-point then this message turns up from an unknown address on an un-defined port, and the IP
routing (quite rightly - or you would be vulnerable to all sorts of attack) discards the packet. However, if the host has already said "send me all the packets on port 6112 (or whatever port) then the packet is forwarded to the host's computer, where the wc2 program already has a socket open listening for UDP
traffic on port 6112.
Once that first message has gone through, the host gives the client a list of addresses for the other clients in the game, and also gives all those other clients the address of the new client joining, and everyone starts sending UDP
packets at everyone else.... and once you have sent an outbound packet over given port to a given address, the IP accepts that your client machine is exchanging data over that port with that external address, so it thereafter routes all incoming traffic to that client.
But, friends and fiends, no amount of server "lag" will make your game lag....
nope, sorry... and here's the proof: what happens when the server crashes during a game? You get a message saying "connection to battle.net lost". This is the TCP
connection timing out. As we know TCP
connections are "guaranteed" by the TCP
protocol. It is internally sending back and forth packets to keep the connection alive and verify that any communication has reached its destination, until your client fails to receive any response from the server for a pre-defined amount of time, when your TCP
drivers give up and notify the client that the connection has been broken.
But when this happens does the game end? No, because the server isn't part of the game, once a game has started you could blow up the server with an RPG
and it wouldn't stop the game. It stops any messaging etc., any command starting with a "/" but the game continues. When the game ends, even if the server is back up and running you don't go back to the channel, you are back in the pre-connection part of WC2, because the wc2 client wasn't written to automatically attempt to re-establish a TCP
connection with the server (this is inherently unsafe as it would have to be storing and re-transmitting your password without your knowledge).
So if there is server lag, it can be slowing down/lagging all the stuff that involves the server: logging in, chatting, messaging, your friend list, getting the game list etc., but it doesn't lag games. Perhaps in theory if there is server lag the TCP
service is generating a little bit more network traffic saying "hello? can you hear me?" a bit more often, but if your network is operating on such a tiny amount of bandwidth that it would even notice this then I would expect that you would already be having all sorts of problems.
So what causes lag? Lag,(or lack of it) is a function of the peer-to-peer UDP
times... or more to the point the worst peer-to-peer route between any two players in the game. There are 2 factors in "worst". Obviously speed is one, but even worse is actual packet loss, where a packet is sent from one place and and just never turns up at its destination. A crackly phone line can do this - or a recalcitrant server (not the game server - just some random internet server). This sort of thing is what causes "conflicts" between two players, that otherwise tend not to have problems. This is because *somewhere* in-between those two end-points is a server that is not doing the right thing with UDP
traffic... or perhaps with all traffic to/from certain locations ... or maybe it's just plain overloaded.
So while we're on the subject, what's with "/ping"?
The "/ping" or "/p" command is not a battle.net command, it's one of the extra features built into PvPGN (that's the software that runs the war2.ru server - it's a battle.net emulator). "Ping" is a basic networking feature which just sends a packet from one computer to another which asks the remote computer to send it back. The "ping" time is the time it takes for the message to go to the remote location, get processed, and return to where it came from. Usually this is repeated a number of times and an average time is reported.
As we know, when you first login to the server, your /ping will be reported as "0". It appears that checking client ping times is either averaged out over number of checks over a reasonably long period of time, or (more likely) it is a task that the server deems to be low priority and schedules it to be done some time when it is twiddling it's thumbs with nothing better to do. So you wait a few minutes and the server reports a time in milliseconds. Try this for fun: on windows go start-->run then type in "cmd"[ENTER]. This will bring up a DOS style command prompt. Then type "ping google.com"[ENTER]. You can do the same thing from a UNIX machine.
The ping reported by the "/ping" command is the round-trip time from server.war2.ru to your client and back again. It does not necessarily have anything at all to do with game lag, although an excessively high number here can be indicative of a network issue. But as we know, lag is related to peer-to-peer UDP
times, connection time to the server has nothing to do with it... although if you have a really slow connection you will also have a high server ping time, but a high server ping time does not necessarily mean you have a slow connection.
Another interesting thing here is that right now, when the server is having some genuine lag issues it is reporting my /ping as 247. This is extremely
low for me (being in AUS). Normally my /ping is reported at 500+. It's just conjecture, but it could be the result of the server's host provider throttling TCP
traffic. As pinging is a "control message", operating on the ICMP
protocol - which is usually prioritised by servers, if the connection is being throttled at the TCP
layer, it could leave other IP
layer traffic with extra bandwidth, hence faster ping times... or maybe they just switched to a host in AUS?...nah lol.
(((EDIT: more likely by the time I wrote this much, iL had already fixed the server issues so it was all nice and speedy, but at the time I assumed it was still having issues, as I was writing not playing)))
So what's with the green/yellow/red bars on the game list and next to each player when you join a game? These are ping times, but are very different ping times. The bars in the game list is the ping time between the host and the server. When you join a game and are waiting - before it starts, as we know, at this stage it's all about peer-to-peer UDP
traffic, so those bars are the ping time between you and that other player. If you see one player go red and the rest stay green, its probably their problem. If you see all players suddenly go red, kick your GF off facebook
IS ANY OF THIS WRONG?....or does some part of it just seem wrong?.... post a reply and tell me what you think!
....and for the extra bonus points... WHO WAS PAYING ATTENTION? - What small change could have been made to the battle.net protocol to eliminate the whole "opening ports" to host a game issue? ? ? I'll post the answer to that later when everyone has just said "FFS, doesn't that nerd ever shut up?" and completely ignored this post.