Client / Server Software

In this post, I'm going to do a brief sort of how it works explanation for client server software.

The reason that I'm doing this is that the next coding lesson will be about creating network sockets on Unix/Linux systems in order to create network software.

There is (as ever) a lot of theory that goes into exactly how network connections etc work.

Rather that try to show horn all that into a single project I thought it'd be easier to post some theory first.

So first, we'll define what is a client, and what's a server.

A server in the context of network software is a program that listens for connections, accepts connections and serves content to those connections, (or receives content from those connections).

A client in the context of network software is a program that connects to another piece of software.

The server listens on specified ports awaiting connections,
The client connects to software that it listening on specified ports.


The network model layers
There is a standard for connecting systems, this is a 7 layer stack called the OSI model, (OSI is Open Systems Interconnection)

Each layer serves the layer above it.

This means that no higher numbered level can exist without the layer below it also existing.
(but you can have lower levels existing withough higher levels in your communication.)

The layers of the OSI model are very well documented elsewhere on the internet, it's a pretty broad subject, and I would suggest reading about it by searching for OSI model, It's practically impossible to break down to a simple blog post.

What is important is that the lessons that I'll be posting now will be using Layer 5 -the session layer of the OSI model. we'll be creating sockets that can be either TCP or UDP, telling the sockets what port we want them to listen on or what port we want them to connect to.
On top of the session level is the presentation layer, this presentation layer sorts out how the data is passed to and from the application layer (your web browser using HTTP) to the session layer (where the IP address is applied) and from there passed down to the transmission layer where it goes off into the world. the presentation layer may not always be used, but when it is used, it generally is used for compression or encryption, or translating between different character sets.

Because we will be accessing the OSI model at level 5 what you do at level six is up to you.

for example you could produce a fairly simple encryption protocol by bit shifting characters such that they appear as gibberish to anybody looking at the packets.
hello world >> ifmmp vlsme
then at the other end, your socket receives gibberish, at layer 5, then your presentation layer (layer 6) sorts that gibberish into real text by bit shifting the other way. and then this data is passed up to your next layer.

The application layer.
The application layer is where many common protocols sit. in general these protocols implement a way for your applications to request data from servers.

A web browser for example uses the HyperText Transfer Protocol.
this is a protocol, (an agreed standard) for the transmission of hyper text.

In general it works a bit like this (very simplistic)
you write https://www.google.com in your address bar.
your application layer passes to your presentation layer.

access www.google.com on port 80 and GET ./ (get the default page at this address)

The presentation layer receives this command, and because it's https (secure) it encrypts your request (GET ./). and passes it to the session layer.

The session layer opens a socket connection to www.google.com on port 80, and passes the data, (which is now encrypted -though the session layer doesn't care all it sees it's a data stream).

If we hadn't encrypted the data then the presentation layer wouldn't have been used at all.


Another thing that is important in these upcoming lessons is that this code will not be portable.

That is that the code will be platform specific, for windows or Linux/Unix systems.

The Linux/Unix software should work on Macs, and will work on raspberry pi devices, but will not work on windows, and the windows software will work on windows, but nothing else.

However the general theory for each is the same.


How socket connections work.
A socket is basically like a data stream, in the same way that we could read or write files, or print to the console using a data stream, we can read and write data to a network socket.


Your server listens on a port, (for a web server this may be port 80).
Your client software creates a port with a random port number, and connects to the server on the service port, it sends information about the port it will be listening on, and it's address
The server accepts the connection on the service port and creates a new port to reply from,
The server send a response from the new port to the client on the port that it established communication to the server on.

The client may then send a message, and the server will respond.

This will be more obvious when I get into the code, but that's going to happen another time.