An introduction to Networking

[deathtaker26]

Hey guys, so as some of you know I'm going to be starting college in January to teach high school programming. So, to prepare myself I'm going to be writing some online tutorials on how to develop games and game engines. I want you to keep in mind these tutorials are not really for an engine, but rather writing games/engines from scratch.

**Where to begin?**

Usually when I develop a game engine or game that I KNOW is going to be multiplayer I like to code the network first, just to get it out of the way. Now somethings you need to keep in mind about networking is not really the code behind the network, but how the network itself functions. Usually I will tell you that the output  is not as important as the code itself, but in this case, the output functionality of the network is EVERYTHING. With a properly coded network you can avoid hacking and major lag. Before you go jumping into code you need a basic understanding of how networks actually function. It's more than just exchanging data. It's breaking down that data and coming to understand what is actually happening in the background of that data transfer. So, let's jump into it!

**What is networking?**

In my definition, i like to describe networking as a handshake or agreement. It's where a server accepts data incoming from a client, and handles that data usually by distributing a feedback stream. A stream is basically the connection a server has with a client. If you could imagine a long tunnel and cars passing through that tunnel the cars are either trying to get from one end of the tunnel to the other. There are not branches or other ends of that tunnel to go to. The cars in this represent the data. One end of the tunnel represents a server, the other a client. Data in a network such as our will never go from one client to the other. It will always reach the server first. If clients are sharing data directly it's called a Peer to Peer network, or p2p for short. p2p networking in gaming is usually used for 2 player games where plays are only connecting to one other client. A network like this doesn't really need a server, but rather a "host". Now don't get me wrong, a host acts as a server, but in p2p, one client will act as a server and the other will act as a client. That server does the majority of handling data and uses the majority of the bandwidth because it's receiving and sending more than the other. This client is known as the Host.

In a network for a rpg where a server actually takes place, the server is the host machine. All the clients are connected to the same server. That server is broken up into multiple sockets and each socket is a different connection. Let me stop here and explain. A socket is basically a networking object in which connections take place. In our case we are going to be using a TCP socket, or Transmission Control Protocol socket. The server will use one socket to listen in for connection. Rather than accepting a connection and using up the single socket, the server will create a new socket that accepts the incoming connection and the listening socket will begin to receive new connections again.

Now, there's something you need to know about TCP. TCP uses a single stream. By this I mean there is one tunnel that is sending and receiving data. It's as if there is a VERY narrow one lane tunnel where cars can go one way or the other. If you send in 2 cars through that tunnel at once they're going to crash. This being said, one bit of data can't go at the same time as another bit of data. This usually isn't a problem when sending data as much as it is receiving it. By that I mean if you send data too quickly, your buffer, or the incoming data, will get jumbled up there for creating what is relatively useless data and the packets, or information, you sent from the client to the server (or vise versa) won't be able to be converted into the data you want. This is something you need to keep in mind.

**What is a proper networking method?**

Alright, so in my book there are 2 kinds of networks. A network that works… and a network that... actually works. Just because your network can transfer data doesn't really mean it's working. As stated above there is one stream in TCP and if you send data too fast it will get jumbled up. So what's the fix? The fix is making the server wait until the data is fully sent to the client before sending another packet through the same socket. The way we do this is by having the client have a reply saying, Hey I'm ready to receive more information. The server end connection will need to do the same. So basically, data comes in and a boolean (true/false variable), which I'm going to call netReady, will be set to false. When the client receives and finishes handling that data, it will send back to the server with a packet saying, I'm done! The server will then flip the switch and set netReady to true and send the next packet. Now keep in mind, this might cost extra unnecessary bandwidth, but this method works for TCP.

**Where can I start?**

The first thing you will need to do to start your network is selecting a networking library. USUALLY I use .net sockets (System.Net.Sockets) I prefer coding based on .net sockets. If you're working with an older language, such as VB6, You should probably use Winsock, or windows socket control, which I believe is what eclipse uses if I remember right. There are also other 3rd party networking libraries such as Lidgren, which I personally am not a fan of, but I hear they're pretty decent. So it's all a matter of personal preference.

**The actual code**

I tried writing a video for this 3 times already and I've been interrupted 8 times already by my stupid dogs… so i'm just going to write a text tutorial later tonight. Sorry guys.

[Sn0w Beast]

Nice introduction. I will check out the vids once you get them up.

[deathtaker26]

> Nice introduction. I will check out the vids once you get them up.

alright it might be a bit though, my dogs are really bothering me tonight since I'm the only one home, so it might be tomorrow.

[Sn0w Beast]

Alright. I will probably be on tomorrow so I'll check back then