Network Programming – Setting the Scene

In Jonathan swift’s satirical novel, Gulliver’s travels, Gulliver comes across two neighboring islands, Lilliput and Blefuscu. Two factions there at a war, the little-endians (Lilliput) and the big-endians (Blefuscu) and dispute concerns, which end of a boiled egg you should open.

Well now a days, it would be nice to think that the world would not squabble over such trivia. However, the little-endian vs big-endian difference does show up when we network computers with differing architecture especially in case of Network byte Order which will discuss shortly.

I was going to title this post as “Linux Network Programming” because to keep the discussion focused I will refer to Linux Socket Api but the concepts are more and less very generic with smaller implementation details differences.

This is my second post in context of TCP/IP and network programming. In this post, I will layout the plan and setup the scene. The focus will be on the following points:

• Sockets (recap)
• Programming Language Selection
• Network Byte Order
• Application Interface
• Client/Server Associate
• Client/Server Architecture

Sockets

Although I have mentioned their role in my previous post at the following link,
https://hexquote.com/pretty-little-things-tcp-ip-ports-and-sockets/
but here I would like to point-out some of the core things about them:

• Sockets provide a way for two processes or programs to communicate over the network.
• Sockets are a method of IPC that allow data to be exchanged between applications, either on same host (computer) or on different hosts connected by a network.
• In a typical client-server scenario, applications communicate using sockets as follows:
  • Each application creates a socket. A socket is the “apparatus” that allows communication, and both applications require one.
  • The server binds its socket to a well-known address (name) so that clients can locate it.

Programming Languages Selection

Traditionally socket Api system calls are documented in terms of their C-language bindings and C is generally considered as lingua franca of linux system programming, but we can use other languages as well.

Choice of language you might use for network programming should come from you, though I will demo it with particular emphasis on C, Python and may be also in C# and you will notice that once you understood the concepts, programming becomes very straight forward and easy.

Network Byte Order

Little-endian vs Big-endian

Remember the reason of conflict between Lilliput and Blefuscu in start of this post? Same sort of thing is happening here.

We will be dealing with network byte orders during our demo and I wanted to get it cleared out in the beginning, so when we use the constructs in code, we have some idea about what this is. I will try to keep it short, and for more information, you can google the terms if needed.

• For example, a big-endian machine would store a 32-bit integer with the most significant byte at the lowest memory address, and if it were to transmit this value over the network, it would send most significant byte first.
• Little-endian machines, like the processor you’ll find inside most pcs, do it the other way around.
• Now the socket’s API says that things have to be done big-endian and this is some times called network byte order.
• There are macros that will convert between network byte order and the machines internal byte order.
  • For 16-bit quantitites, htons (host-to-network short) and ntohs (network-to-host short).
  • For 32-bit quantities, similarly then 32-bit version of that htonl (host-to-network long) and ntohl (network-to-host long).
• On a big-endian machines, these macros don’t actually do anything.

Application Layer and Socket API

• Our focus is the interface b/w an application and the transport layer of the TCP/IP stack, which are TCP and UDP protocols, these in turn lie on top of IP protocol.
• The interface b/w the application program of a transport layer is known as socket api and here is our focus lies, in particular, on system calls like:
  • socket()
  • bind()
  • Listen()
  • accept() and connect()

Client/Server Association

• TCP/IP protocol is a natural client/server association.
• The server end-point address consists of the IP Address of the machine where the server is running plus the 16-bit port number. Now for established services, these port numbers are standardized (e.g. port 80 for web server).
• Now, the client also has an end-point address consisting of an IP address and port number. However, the client choice of port no. is largely irrelevant.
• Its these four things (red dotted lines) that defines a TCP connection. If any of the four is different; it’s a different connection. That’s make it possible to have 2-clients on same machine connected to same server, because each client will have different port no (so a different connection).

Client/Server Relationship (Server)

For most of the demo parts, we will be writing clients and servers and lets make the distinction between these two very clear.

• The server offer a service:
  • Establishes a “communication endpoint”
  • Passively waits for business.

Service could be something simple like telling you the time, or something more complex like providing web content or running SQL queries against a database.

To do this, it needs to create a communication endpoint on address of some sort that’s known to its potential clients. In context of this post, this endpoint is called a socket.

Having set this up, it sits and waits passively for a client to come along. It might wait for hours or it might be a very popular busy server receiving many request every second.

Client/Server Relationship (Client)

Actively connects to the Server.

A client, on the other hand, consumes a service by actively making a connection to server with its known endpoint address. It makes a request and receives a reply.

Typically:

• Client is local
• Server is remote

However, that’s not the defining feature of client/server relationship

I would like to conclude this post now regarding setting up the scene. In the next part, we will write some code and see how all this can be implemented in a programming language.
Feel free to leave comments, if something is not clear or you need more information and I will try to provide you some answer or direction in this regard. Till then, Happy Coding!