Networking for flightsimmers
Your computer system is hard at work for you when you’re running a flightsim. It’s simulating the dynamics of the aircraft, and those of the weapons you use. It’s drawing all the pretty pictures you see when you look outside the cockpit. It may even be simulating a full-on war raging all around you. And when you’re running a network game it’s also taking care of sending all kinds of data from the program that you’re running to the program that your fellow players are running. There’s a whole bunch of system software (sometimes called the “networking stack”, since it’s constructed like a stack of layers on top of each other) that’s making sure all your data gets to the other guys, and their data gets to you.
This page is about much of what those networking stacks get up to. It is an attempt to explain the terms you may encounter when reading about network games and their relevance to the flightsim you’re running. It will also attempt to explain why networking works like it does, why you have to type in all those strange numbers like IP addresses and port numbers (and what they are) and how routers and firewalls sometimes wreck your network games (and what to do about it). It is not a step-by-step howto on getting all kinds of flightsims to communicate successfully, but rather an explanation of the stuff that goes on in the background, with (hopefully) the result that you can solve some of your networking problems yourself. We’ll go a bit into the particulars for Falcon 4.0, partly because it’s probably the most popular multiplayer combat sim out there, but mostly because it’s the most finicky to get working.
TCP and UDP
There’s two terms we have to talk about first, and you’ve probably heard or seen them before: UDP and TCP. The meaning of that first acronym is “User Datagram Protocol”, the second one is “Transfer Control Protocol”. You can forget those meanings right away, but it might be wise to remember that the D in UDP stands for Datagram. It points to the main difference (as far as we’re concerned) that separates it from TCP: UDP is for sending datagrams, quite simply packets of bytes that are sent across a network cable from one computer system to another.
The bad news is: if for some reason those packets don’t reach their destination: tough luck. It’s had its chance, and if you weren’t listening when it arrived because you chose to unplug your network cable at just that moment you’ve only got yourself to blame. A UDP packet is like a postcard: there’s no guaranteed delivery. It can get lost anywhere along the way: maybe the post office burnt down, maybe the mailman delivering it got hit by a bus or maybe he chose to “lose” his mail in a dumpster and go to the beach instead. What’s more, if you’re sending a number of UDP packets in a row there’s no guarantee that they’ll arrive in the same order. Just like when you’re making a trip around the world and you send a postcard home from every country you visit, some will arrive out of order and some may never make it at all. That’s UDP.
TCP is different. TCP is more like a conversation over a perfect telephone line: you set up the connection beforehand, and then you just start sending data packets down the line. They will all get to the other side without bits missing and in the right order, just the way you sent them. In reality, TCP packets get lost just like UDP packets do, but the difference is that the systems you’re using for the connection employ a little guy who monitors the stream of packets and makes sure every packet that is sent is received at the other end, and in the right order. To go back to our postcard analogy: it’s like there are two postal workers monitoring the stream of postcards on both ends and making sure everything that’s sent gets received at the other side, completely and in the right order. When a postcard doesn’t get through they’ll notify their colleague at the other end and ask him to resend it. Short and sweet: TCP gives you a reliable connection, UDP is unreliable.
(One interesting factoid is that the systems talking to each other use packets of their own to keep each other posted on which packets arrived safely, and which have to be resent. All these extra packets can be lost too, of course. Dealing with all this makes the TCP protocol quite, er, interesting.)
Alright then, why would anyone use unreliable UDP if there’s something like reliable TCP? Well, TCP does guarantee that all postcards (or packets) get there, but it may take some time. If some packets go missing the receiving system will tell the sender those packets need to be resent. Any packets received after the ones that went AWOL will be held in a queue by the receiver until all the missing bits have been received, and at that point everything will be delivered in the right order to the receiving program. This way the order in which they are received is the same as the order in which they were sent.
Now suppose those packets contain position-updates being sent from a squad-mate to you in an internet- or LAN-game of Falcon, and just when you’re on his six one position update goes AWOL. Just about the worst thing that could happen at that point is if the little guy on your end of the connection says “Whoa, wait a minute. I’m missing something here”, asks his colleague on the other end if he could please resend the missing packet and then just sits there twiddling his thumbs until it arrives. You would much rather forget the missing data and continue with the next one to follow. Falcon (and all other flightsims that want to offer networked multiplayer with any degree of success) have algorithms to extrapolate player positions from previous data anyway, so a missing update just means they’ll have to extrapolate a little further. For them it’s all in a day’s work, and you probably won’t even notice that some updates are missing. But if your squad-mate suddenly stops in mid-air and then warps back ahead of you, just because the stream of packets was held up waiting for a few missing ones you will certainly notice. When it comes to this kind of data, UDP’s speedy delivery is much more important than TCP’s completeness.
Ports and adresses
Very well then. Let’s first talk about the simplest case: two computers, each with a single network card, connected to a single network segment (effectively a single wire). This is something you would see at a LAN party. This is pretty straightforward: When one PC wants to send a bit of data to another it writes a postcard (or packet) with a destination address on it and puts it out on the wire. The receiving computer sees a packet going by that has its address as the destination on it and picks it up. It’s then delivered to an application inside the receiving computer.
The address that’s written on the postcard is an IP-address, the address of one of those network stacks we talked about earlier. Every network card (also knows as ethernet cards or, more formally NICs: Network Interface Cards) in your system has a network stack associated with it, so every network card has its own IP address. IP stands for Internet Protocol, and it’s the protocol that underlies both the TCP and UDP protocols. TCP and UDP have their own layers in the stack and IP is simply the next layer down. TCP is more formally known as TCP/IP because it is built on top of the IP protocol, and likewise, UDP is sometimes called UDP/IP. If you have a broadband connection (and who doesn’t) or you have ever played any networked multiplayer game at all (and who hasn’t) you’ll probably be intimately familiar with IP addresses.
(By the way, you’re probably reading this using a web browser. That browser uses HTTP, the HyperText Transfer Protocol, which is handled by another layer on top of TCP. See? It’s all layers.)
Now you probably have more programs than just your flightsim running. You may have an IM client like ICQ running, or you may have a web browser running. All these programs need to send packets of their own (either UDP or TCP), so just having an IP address isn’t enough. Your browser wouldn’t know what to do with the Falcon multiplayer packets. And, knowing Falcon, it would probably crash if it received a packet meant for your web browser. So you need another way to make sure the right packets end up at the right program. This is where ports come in.
Ports are entry points into a networking stack. Every networking stack has 65536 of them, numbered 0 to 65535. Every packet that enters or leaves a computer goes through a port, and they all have the IP address of both the sending and receiving system, and the ports through which they were sent and received inside them (we’ll soon discover why this is a good thing). The IP address and port number of the sender are called the source IP address and port number (IP and port for short), those of the receiver are the destination IP and port.
To stretch our postcard analogy a little further: IP addresses are like the street address of the post office and the ports are the little post office boxes inside. You can send a postcard to the address of the post office, but to make sure it ends up with the correct person you’ll have to specify a box number.
DHCP
How does a computer on a network get an IP address? Well, there are basically two ways: using static addresses and using DHCP (to be honest: there’s lots more ways, but those don’t concern us for the moment). Static means that you go into your TCP/IP settings, check “Use the following IP address” and enter an address. That address is now your IP address, at least until you change it again. This is often quite sufficient (in fact it was the only way during the early years of the Internet) but it does have its drawbacks, the main one of which is that it’s, as the name implies, static. Any computer that connects to a network must have its own unique address and you have to maintain the assignment of IP addresses to computers by hand. In the old days this wasn’t a problem because installing or removing a computer involved heavy equipment to winch heavy steel computer cabinets into air-conditioned server rooms. You didn’t do this very often, so the extra effort for maintaining an IP administration was quite small. Nowadays adding a computer to a network is as easy as plugging in a laptop (or just switching it on if it has a wifi card), and keeping tabs on which computer uses what address becomes quite a chore.
Enter DHCP (Dynamic Host Configuration Protocol). DHCP basically automates the administration of those IP addresses. Instead of a network administrator who has to assign IP addresses there is one computer on the network that runs a DHCP server. Whenever a computer starts up it will call out on the network for an IP address, the DHCP server picks up this request, searches its internal administration for an unused IP address and sends it back to the computer that sent the request. This assigns the provided IP address to its network interface and from then everything runs as if the IP address was statically set. The DHCP server marks the IP address as “used” so the next computer to request an IP address gets the next free one. The server also tells the clients how long the IP address will be valid (about a day, usually), so if the computer wants to keep using it, it’ll ask for an extension (which is granted, barring unusual circumstances) before it expires. This all occurs in the background of course, the user behind the computer doesn’t notice any of this.
Routers and firewalls
So, we talked about a bunch of computers on the same physical network, i.e. on the same wire. It’s easy to see how the packets are received by a system, because anything a sender puts out on the wire can be picked up by any receiver. But in the Great Outdoors known as the Internet things go a little differently. This is a good thing, because otherwise the Internet would quickly get clogged by all the packets from every computer Out There.
On the Internet we have routers. Those are like electronic spiders, sitting at the center of a web of network cables, and when a packet comes in on one wire they look at the destination address, decide which wire leads to that address and send it out again on that wire. That wire may lead to another spider a little closer to the destination, who will do the same again, and so on until the packet finally ends up at the wire that is connected directly to the destination system. That system will see a packet on the wire with its address, pick it off, read the destination port and deliver it to any program that has opened that port. The “jumps” that a packet made from one wire to another, helped by an electronic spider/router are called hops.
(You can see the hops that a packet takes from your system to any other using a nifty little program called pathping on Windows XP (it’s based on a UNIX program called traceroute). It shows you the route that a packet takes from your system to any other by specifying the destination IP. Try it (in a Command Prompt window), you’ll be surprised how many hops it takes from your system to even a system that you thought was close to you.)
(So what happens when a packet is delivered to a port where no-one is listening? Well, nothing basically, other than an error message that is sent back to the originating system. No-one can “break in” to a computer through a port where no-one is listening. The fact that any Windows PC’s security is compromised within half an hour of it being connected to the Internet is caused by programs that Microsoft installs by default, that listen on a port with a fixed, well-known number and that can be cracked by anyone sending it a malicious packet.)
Firewalls are, in a way, a special type of router. The difference is that routers unconditionally send out any packet it receives (with some exceptions which we’ll talk about a little further down), whereas a firewall earns a living by blocking most packets and only letting through a very specific subset. It does this by looking at the destination port. Packets with destination ports that are specified as being OK (such as port 80 for web servers) are sent through, all others simply dropped. This way any system behind the firewall that has potentially dangerous ports open are safe from those malicious packets. If you are behind a firewall and you want to be able to play some types of on-line game you may have to specify more ports that should be allowed.
Special addresses and ports
All IP addresses and port numbers are equal. But of course some are more equal than others. There are a whole lot of IP addresses that have been banished from the Internet and are sentenced to a lifetime on small, internal LANs without any access to the outside world. These are called private IP addresses. Any packets travelling on the internet and going to an address in one of these ranges will be summarily dropped by the first router that encounters them, because it knows that none of these addresses should be connected directly to the Internet. Besides, there are probably thousands if not millions of systems with any such address behind firewalls in the world. Which one would the packet be for? There’s simply no way to know.
There are three ranges of these addresses:
- 10.0.0.0 upto 10.255.255.255
- 172.16.0.0 upto 172.31.255.255
- 192.168.0.0 upto 192.168.255.255
You may recognize some of these addresses. They are often used in small networks that are not connected directly to the Internet, such as those used during LAN parties. You will often find addresses like 192.168.1.1 there: straight from the third range of addresses. These networks can only be connected to the Internet by using a gateway: a system that has two network interfaces (network cards with their associated network stack), one of which is connected to the internal, private network and one which is connected to the Internet. Both network cards use their own IP address: the one connected to the private network has an address from one of the ranges above (192.168.1.1 and 192.168.0.1 are popular choices), the one connected to the Internet has an address that is provided by the Internet provider (usually set using DHCP).
In fact, certain types of ADSL modems (the Alcatel SpeedTouch 510 and 530 for example) use a comparable scheme. The function of the gateway PC is taken over by the modem itself: it too has a private IP connected to an internal network and an external IP which is set by the provider. There are (at least) two devices connected to the internal network: the modem itself (with its own private IP of, usually, 10.0.0.138) and your computer (or computers) with a private IP in the same 10.0.0.x range. From this point I will call the IP address with which the modem is connected to the Internet the external IP and the IP of the computer(s) on the internal network the internal IP.
(These modems emulate “real” PCs in more ways than one: they usually have a small web server embedded which is reachable on its own internal IP as http://10.0.0.138/. The modem can then be configured using this “web”-page.)
Apart from special IP addresses there are also a number of special port numbers (although, to be fair, they’re not quite as special as the special IP addresses). These are collectively known as well-known ports. One of these has already been mentioned: port 80 for web-servers. Some others are 21 (FTP, File Transfer Protocol), 25 (SMTP, for e-mail), 137, 138 and 139 (netbios, for connecting and accessing Windows shares) or 194 (IRC, Internet Relay Chat). They belong to the ports with numbers smaller than 1024, the so-called low port numbers. These usually have special security precautions (programs sometimes need special privileges to open them) because so many crucial Internet protocols depend on them. Higher numbers can be used by other programs.
NAT and Port-forwarding
Now sharp-eyed readers may have spotted a problem here. Let’s suppose someone is using a PC with one of these “internal” IPs, connected to the internet through a gateway, and I want to connect to it. Every gateway between me and him will drop any packets with his destination IP, so how do I connect to him? For that matter, if I have such a system how do I connect to others if they can’t send any packets back to me? The answer is NAT (or sometimes NAPT) for Network Address (and Port) Translation.
NAT is something that the gateway between the Internet and your own internal network does. Let’s suppose that the internal system (on the internal network, with an IP like 192.168.1.1 or 10.0.0.138) wants to set up a connection to a system somewhere on the Internet. It will send out the appropriate packet onto the internal network and this will be picked up by the gateway as something that needs to be forwarded onto the Internet. However, before it does so it will replace the source IP (which is from the internal network and therefore useless on the Internet) by its own IP, and it will replace the source port with the port it is using to send the packet out. So, for anyone who sees the packet on the Internet it will look like it came from a bonafide Internet host, even though its origins lie on a private network.
When the packet arrives at the destination it will be handled like any other. The destination system will read the source IP and port and will reply by sending a response to that IP and port, oblivious to the fact that the packet didn’t actually originate there. When the response arrives at the gateway it will remember that the particular IP/port combination where it arrives was set up on behalf of a system on the internal network, so now it will replace the destination IP and port with the ones it recorded from the original packet and send the changed packet out onto the internal network. The originating system sees a packet with its own IP as the destination, picks it off the network and hands it off to the program that opened the port. Mission accomplished! Two packets have found their way and back, and neither system has a clue what kind of tomfoolery was perpetrated on their behalf. The gateway will keep a record of the necessary translations until it sees the connection being taken down again, so any dialogue between the two systems gets the same treatment and none of them is any the wiser.
Things get a little more complicated if the destination system itself is behind a gateway. Again, the source system cannot just send out packets with the internal IP of the destination because they will be dropped at the first gateway or router that sees them. So we need another trick. This time, the gateway between the Internet and the destination’s internal network has to be told that packets coming in on a certain port (or range of ports) should be redirected to the same port on the internal IP of the destination, a mechanism known as port forwarding. Any packets coming in on that port or port-range will have its destination IP replaced with the internal IP and be sent out again on the internal network. The destination system will pick those packets off the network and process them as usual. Any responses going the other way will have their source IPs replaced by the gateway with its external IP before they’re sent out on the Internet. So again, neither system suspects anything special is going on.
All this explains why people need to pull all kinds of tricks to play flight-sims across a gateway or firewall. In the case of Falcon there’s an extra complication: when Falcon sends its initial packets to another system, one of the things it reports is the IP of the machine on which it is running. If this is an internal IP of the sort discussed above we’re in trouble, because that IP will be useless once packets start flying over the Internet. What we need to do is tell the gateway that packets coming in on any of the ports that Falcon uses should be forwarded to the (internal) system that is actually running Falcon, and we have to tell all other players to send their packets to the (external) IP of the gateway separating us from the Internet. The first is done by careful setting of port-forwarding parameters on the gateway, the second is done by using the -ip command line parameter of Falcon. This instructs Falcon to report the given IP address instead of the one it gets from the system on which it is running. All other systems will use this IP to send packets to us, and the firewall will take care of the NAT and port-forwarding. Just what we want.
And it doesn’t end there. If a system has more than one network interface Falcon also needs to know which interface it should use for its network traffic. You could have a Windows machine acting as a gateway for a number of systems on your internal network using Internet Connection Sharing, Microsoft’s version of NAT. This system will have two network cards (one connected to the internal network and one connected to the Internet) and if you want to run Falcon on the gateway it doesn’t help if Falcon starts sending its packets onto the internal network. So in that case you can use the netchk program (located in your Falcon4 folder) to find out which IP adress belongs to which interface. This will output something like this:
C:\\Microprose\\Falcon>netchk ..ComIPHostIDGet 0: [windows] <your-external-ip> ..ComIPHostIDGet 1: [windows] 192.168.1.1
You can then add a command-line switch -hostidx
C:\\Microprose\\Falcon>hostidx 0
This enters the number in the registry so you don’t have to enter it on the command line.
This doesn’t apply to most people, though. Remember that you only have to worry about the -ip parameter if you’re behind a firewall or gateway, and you only have to worry about the -hostidx flag if you have more than one network interface.
Conclusion
This ends our little excursion into the world of networking. I hope this has clarified some of the lingo used, and has provided some insight into the mechanisms that underlie the big ball o’ wires known as the Internet. There’s a lot I haven’t even touched on yet, maybe we can go into that later. For now, my best regards, watch your six and keep your canopy pointing towards the blue stuff.
comments off Jacco