« All Software Development Articles

Networking for Application Developers 1 of 3: IP

4/9/2021
  1. Networking for Application Developers 1 of 3: IP
  2. Networking for Application Developers 2 of 3: TCP
  3. Networking for Application Developers 3 of 3: HTTP

Introduction

Application developers should had a deep understanding of networking concepts, but often don't come across low level details. Many times they are abstracted or virtualized, hidden to applications, even hidden to the operating systems that are accessing them. However, developers will work with TCP/IP just about every day.

Models

The common model many in the industry will discuss is the OSI Model. The OSI Model is also taught in schools. It's a seven layer model first created to describe abstract network intercommunication and was invented by early internet forerunners in government and the private-sector. Today, it is useful for more networking-focused discussions, separating out lower layers in the stack. For example, Ethernet and Bluetooth are Physical Layer protocols. However, in today's internet the de facto standard for mobile and desktop applications to communicate with each other is TCP/IP.

The TCP/IP Model is a simplification of the network model. It specifies which protocols are used at each step which combines the layers from the OSI Model into a more compact, four layer model. However, much of the abstraction is lost, and model layers know about the implementations of the layers around them. For example, the higher Application layer must understand the IP Address which is part of the lower Internet layer.

TCP/IP: Internet Protocol Suite

The TCP/IP set of protocols was developed by the U.S. Defense Advanced Research Projects Agency (DARPA) in the 1970's. It was widely adopted in 1980's, used by companies like IBM and AT&T as well as the U.S. military. By the 1990's it was built in to all modern operating systems like the incredibly awesome Windows 95. The four layers from lowest to highest are below.

  1. Link
  2. Internet
  3. Transport
  4. Application

Link Layer

This layer includes concepts such as MAC addresses, Ethernet, switches, and the hardware that transmits and encodes signals. Application developers can save the study of this magic for another time.

Internet

The internet layer defines how networks communicate with each other, or internetworking. If my computer was directly wired to yours this wouldn't be needed. However, the internet is a web of computers, routers, and ISP's, that all agree to pass along messages from unrelated senders to the next member of the web, until finally a message reaches it's destination.

The Internet Protocol, or IP, is the treaty by which all of these parties agree to participate. After leaving the sender, a message hops along intermediate nodes until it happily reaches the intended recipient. When it works everyone gets to send and recieve the information they want. If you're reading this, this mostly decentralized system still works pretty well.

The IP Address is the way to identify the virtual location of a computer on the internet. IP Addresses come in two flavors, IPv4 and IPv6. Because of the limited total number of IPv4 addresses the world started running out of addresses in the 1990's.

To solve this problem two solutions arose. The first is network address translation, or NAT, where a router uses one public IPv4 Address and coordinates traffic with local computers with private IPv4 address. This way, your computer on your local network can have the same local IPv4 address as my computer on my local network. The second is IPv6, where the address is defined in a way where there are many, many more possible addresses and running out is not a problem. If possible, programs and operating systems will attempt to use IPv6 but adoption has been slow and NAT/IPv4 is still common.

The ipconfig tool on Windows or ifconfig on Linux shows machine level information such as your own local IP address. The output below shows this computer's network supports IPv4 and IPv6.


PS C:\Users\Steve> ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : localnetwork.com
   IPv6 Address. . . . . . . . . . . : 3301:ca8:21bb:7:712e:acc6:d155:311b
   Temporary IPv6 Address. . . . . . : 3301:ca8:21bb:7:5129:baa4:9551:21ba
   Link-local IPv6 Address . . . . . : ab80::117b:234a:14dd:a11d%3
   IPv4 Address. . . . . . . . . . . : 192.168.1.99
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6
   IPv4 Default Gateway  . . . . . . : 192.168.1.1

Computer operating systems discover IP addresses using the Domain Name System, or DNS, which is not covered in this article. To find the IP address for a domain name use the nslookup tool. The output below displays IPv4 addresses only.


PS C:\Users\Steve> nslookup stevewakeford.com
Server:  dns.localnetwork.com
Address:  192.168.1.1

Non-authoritative answer:
Name:    stevewakeford.com
Address:  74.208.236.186

Now that the machine can find the IP Address of the web server it wants to communicate with it needs to create a message and send it off. The message is called a packet. To send a test packet to a destination use the ping tool. Hey, average round trip time is 23 milliseconds, not bad! Support for simple tools like ping and tracert is built into IP.


PS C:\Users\Steve>  ping stevewakeford.com

Pinging stevewakeford.com [74.208.236.186] with 32 bytes of data:
Reply from 74.208.236.186: bytes=32 time=23ms TTL=54
Reply from 74.208.236.186: bytes=32 time=23ms TTL=54
Reply from 74.208.236.186: bytes=32 time=23ms TTL=54
Reply from 74.208.236.186: bytes=32 time=24ms TTL=54

Ping statistics for 74.208.236.186:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 24ms, Average = 23ms

This layer is defined as a connectionless, best-effort delivery system. This means that data packets are "fire-and-forget". The source computer sends a packet at the user's request but, at this layer, there is really no way to "hold the line open" to the receiving computer (connectionless) or confirm the packet reached the destination (best-effort delivery). At higher layers we'll see how these issues are overcome.

Done

Check out the next article in the series Networking for Application Developers 2 of 3: TCP. If you have any feedback or corrections please let me know on my contact page.

Have a nice day.