Overview

In Second year of University, I tackled my first networking project, the premise was to take a framework using C# and Monogame libraries with one paddle and a ball and turn it into pong that can be played over a network. This project was very challenging for two main reasons, multithreading the project and serialising and sending the data over the internet.

This project contains several low-level implementations including Multithreaded server and client, TCP and UDP connections for sending data, custom JSON packets to store data and encryption to secure the data over the network.

Grade: First

Image of Games Lobby

Running in Parallel

The first challenge of networking happens before even thinking of connecting to the network, how can a program run a game at the same time as waiting for messages from the client or server. Each client utilises a listener which its only purpose is to wait for a message to be received and handle it, in the case of this project it will receive an encrypted packet and send it off to be decrypted then depending on the info contained handle it. This listener is a blocking call meaning the program will wait until a message is received this is undesired for two main reasons the first is the program will not run anything until a message is received this includes if the client is in the lobby waiting for the host to press play, the other is in order to not multithread this the program will need to send multiple packets a second to force it forward this will not only lag the program trying to read the many messages but also clog the band width. For these reasons the listener was put on its own thread allowing it to wait for a message without affecting the progressing of the program.

Game Restart Menu

Across the PongVerse

All computers connected to the internet require information as to where to send information and where that information came from, in both scenarios if the computer is unaware then that packet is dropped and not read for security reasons. This meant that the program had to create a connection between the server and the client they are playing against, the most common ways of sending information across the networks are TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).
TCP has also been dubbed the handshake connection as for a connection to be made both clients must send a packet to each other and save the return address, this constant connection also requires that all data is sent and received in order should a packet not arrive the connection can request that packet be resent.
UDP on the other hand uses a connectionless method all that is required for sending packets is the address, this method is considerably more lightweight than TCP as the packets don’t need to contain the extra info required by TCP however there is a drawback, as the packets don’t contain the order they where sent in or a pre warning the packet is coming if the packet doesn’t arrive the program has no real way on knowing. For my project I incorporated both to demonstrate their uses.

Both Clients Connected

Bringing Security

Both TCP and UDP are not secure should someone listen in and pick up packets they can pretend to be the second client and cause damage. In order to stop this, I encrypted my packets to send across the network, using public and private keys and passing them off to each client using the server.