14 - Into to Networking

Class: CSCE-313

Notes:

3rd midterm on Friday 4/24 or Mon 4/27

Try to work out problems under Weekly-HW

• Doing this will help you understand the material better

What is a network?

Notes:

• Every device that you will probably ever used is at the edge of the network, you are always connecting at the edge
• You are connecting from something called an Access Point, that is then connected to the network
• If you connect a Cat6 cable to you PC, you are connecting from the edge
• Something inside is able to make a connection from you from whenever you are in the entire planet
• We are just interested in the API at the end devices, we are interested on that software that enables us to connect to the internet

The network does the routing

Notes:

• The only thing you know is how to reach your default gateway (the first hope device in the network that knows a lot more about the network than you do)
• Lets say you want to get to google.com, you create a packet and just send it to your gateway, it will receive it, parse it and route to wherever you are directing to.
  • For every packet you have to read it from your NIC into your memory, parse it...
• The gateway decides on which direction to go, it does some hash or search in order to figure out on which direction to send it

The Internet: a "nuts and bolts" view

...

Notes:

• Every blue region is a network
  • You may be in your home and all the devices in your home may be connected to an access point
  • Traffic from your phone is going from devices to your router to your local ISP (optimum, etc.) - they server either your local area or some region
• There is this notion of an Autonomous system in the internet: it is an independently managed network
  • They own certain set of pre-fixes and advertise them, when you want to reach a destination, you basically route it to the autonomous system
• It is actually pretty fragmented for a lot of reasons
• Billions of connected devices
• Switches route at layer 2
• Routers route at layer 3

"Fun" Internet-connected devices

...

Notes:

• They all want to be first-class citizens at the edge
• They are truly first-class entities in the network, but unfortunately they cannot always can be due to addressing limitations

The functionality of "networking"

....

Notes:

• One of the functionalities of the network API is the ability to name devices at the edge
  • The way you communicate with someone is that you construct a packet, you put your destinations 32-bit number, you put your own 32-bit number as the source and you forward it to the network so that it gets routed to your destination.
  • The cloud in the middle does the route for you, you just need to name an endpoint
• Modern networking is packet switched rather than connection-based
  • Split conversation into little discrete packets, each of these packets has a destination and source IP
  • We are individually routing each of these packets
    • every individual packet is routed independently
    • they do not necessarily need to take the same path on the network
  • These packets can arrive out of order
    • The third packet comes first, then the first, then the second for example
    • The endpoint needs to do something in order to assemble the plackets in order
  • It also can happen that a packet gets duplicated
  • Every node in the middle will receive the packet, search for its destination and forward to the next node in the network.
  • We need to have some convoluted logic in order to figure out reassembly of packages and re-fragmenting, removing duplicates
  • But all of this is being done for you and its done at the edge!
• There is a notion of connection
  • The sender and the receiver sort of agree that they are going to exchange messages, but before starting to send messages they need to set up a connection
  • Is not like once you reach the end of some counter you have to break the connection
• The throughput in the network can suddenly change if network gets congested
  • The endpoints can figure this out and slow down the transmission rate
  • How this happens is also something that your networking stack is able to figure out
  • There are other signals to figure out that something bad is happening in the network

Routing

...

Packet forwarding

...

Notes:

• Lets say you want to go from San Jose to Northampton
  • If you could give the exact destination address of Northampton then that is fantastic
  • But every node needs to know the exact destination
• You need to compress all the addresses into one city
  • You can coalesced further and say you want to get first to a city closer to it
• Given an IP address, it will make the prefix smaller and smaller on each pass
• Once you get to the owner of that prefix, then the owner can route you to the destination
• Your packet has a destination, the local guy is able to look at your destination IP and say "go here", the vector is referred to direction, and distance refers to how far.
  • All that routers do is to say: "Out of my n interfaces, This packet should go out on this interface"

Examples:

┌──(macc㉿kaliLab)-[~]
└─$ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.64.2  netmask 255.255.255.0  broadcast 192.168.64.255
        inet6 fd15:7568:1b93:9ef1:49a9:ac71:34f7:cb32  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::60cf:81ff:fe55:308d  prefixlen 64  scopeid 0x20<link>
        inet6 fd15:7568:1b93:9ef1:60cf:81ff:fe55:308d  prefixlen 64  scopeid 0x0<global>
        ether 62:cf:81:55:30:8d  txqueuelen 1000  (Ethernet)
        RX packets 129735  bytes 97878313 (93.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 111498  bytes 19126431 (18.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3450  bytes 13001871 (12.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3450  bytes 13001871 (12.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.10.14.2  netmask 255.255.254.0  destination 10.10.14.2
        inet6 fe80::8af5:89d2:6df1:a2d0  prefixlen 64  scopeid 0x20<link>
        inet6 dead:beef:2::1000  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500(UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 2821 (2.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• The IP address of my VM is 192.168.64.2

Protocol Layering

...

Notes:

• You are independent of what is at layer l - 1, l - 2 and so on.
• You can write you layer M by using functionality entirely at layer M - 1
• When you connect via ssh to your VM, every keystroke that you type can be converted to a packet that gets send to your VM
  • Your ssh client is at layer 5 (application layer)
  • On layer 4 there will be a header encapsulating the your message with metadata of whatever the functionality of layer 4
  • Layer 3 will do the same, at a header to the encapsulated message from layer 4 and encapsulate it again
    • Layer 3 worries about what is going to happen if a frame is fragmented in the middle of the network, how it can be reconstructed, it also needs to put destination on source IP headers and so on.
  • The layer 2 further adds its header and so on
• All of this layer is happening so that this guy uses its functionality of the previous layer and so on.
• Every character you type is potentially going through a different route that the endpoint has to later reassemble

The open system interconnection (OSI) model

...

Notes:

• In the US, they do not split them into exactly 7 layers, the last 3 layers are consolidated into the Application layer so that the application decides what to do exactly.
• You assume that any package you send will get to the other end
• There is a notion of session in protocols like HTTPS
  • You can make a connection, come back, and 5 seconds later you do session resumption
  • IT is very expensive to do cryptography so you set up your keys once, and then when you come back you resume your session.

The TCP/IP Reference Model

...

Notes:

• They do not have separate layers, you still need to do those, but it is the application that takes care of them

A client-server transaction

....

Notes:

• Here you have a client that makes a request to the server, and the server first gets the request, parses the request, and does what it needs to do

What's a protocol?

...

Notes

• In order to communicate effectively we need an understanding between the client and the server
  • Alice makes a request
  • Bob replies

Example of a client-server protocol:

curl

• Allows you to make HTTP request
• The server will read the request and serve the request

Example

┌──(macc㉿kaliLab)-[~]
└─$ curl -v https://www.google.com

• name resolves into addresses
• When you want to covert this name into an IP address, you will get a bunch of them
• Google will rotate these addresses, so if you make multiple requests it will go to different sites hosting the same, that is how load balancing works.

Here is the request that was send:

* Connected to www.google.com (142.251.151.119) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.google.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.google.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.15.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: www.google.com
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off

Response looks like:

< HTTP/2 200
< date: Mon, 06 Apr 2026 19:36:58 GMT
< expires: -1
< cache-control: private, max-age=0
< content-type: text/html; charset=ISO-8859-1
< content-security-policy-report-only:
...

IP datagram

...

Notes:

• Think of the Internet as one big homogenous cloud
  • It is nothing like this but you can assume so for now
• You are at the edge of this cloud
• We are only interested from going from one edge, somehow through this fabric, to another edge.
• Remember IP is implemented at layer 3.
  • What your stack is doing is to discretize into little packets, they go into a network pipe, as these packets reach the other end, something on the other end is fixing the sequence.
  • Every packet is at the IP layer
• IP header:
  • It has a source ip address (32 bits)
  • It has a destination ip address (32 bits)
• DNS is what translates human readable names to addresses.
• Encapsulated within L3 is L4
  • Inside an IP packet there is a TCP packet

TCP header

...

Notes:

• If you are going to http you will store 80 on dst port
• If you are going to https you will store 443 on dst port, and so on.
• It does checksums, reliability using forward sequence numbers and so on.

A programmer's view of the Internet

...

Notes:

• For each of your interfaces you will get an IP address

Example:

> nslookup www.cs.tamu.edu
Server:         128.194.254.1
Address:        128.194.254.1#53

www.cs.tamu.edu canonical name = redirect.engr.tamu.edu.
redirect.engr.tamu.edu  canonical name = d3s3b8hbw2bor0.cloudfront.net.
Name:   d3s3b8hbw2bor0.cloudfront.net
Address: 3.169.221.28
Name:   d3s3b8hbw2bor0.cloudfront.net
Address: 3.169.221.94
Name:   d3s3b8hbw2bor0.cloudfront.net
Address: 3.169.221.95
Name:   d3s3b8hbw2bor0.cloudfront.net
Address: 3.169.221.22

• It corresponds to a machine somewhere sitting in TAMU
• As it turns out, it has 4 different IP addresses that you can reach out

> dig +short www.google.com
142.251.152.119
142.251.153.119
142.251.154.119
142.251.155.119
142.251.156.119
142.251.157.119
142.251.150.119
142.251.151.119

• When you reach to google.com in your browser you are picking one of these!
• Note if you do it again, the order of the entries would change, this is because of the load balancing made by google.

IP Addresses

...

Notes:

• We will only look at IPv4 in this class
• IP addresses are packed in this struct:

  struct in_addr {
  	in_addr_t s_addr;
  }
  

  • This is just a 32-bit struct that serves as a wrapper to tell that this value is of type Internet Address.

Byte order for shorts and ints

...

Notes:

• This example illustrates endianness of network architecture
• Number is just a hex value (i.e. 0x01020304)
• If you are reading this number like that you are inherently assuming endianness, but different architectures do different things
• We have these two big forms:
  • Little endian
  • Big endian
• Code:
  • You will do the assignment, then print the first 4 bytes
  • A function called htonl means: host to network long
  • Once we have turn a to this "network long" we do this again

Result:

Host BO: 4 3 2 1
Network BO: 1 2 3 4
inet_ntop: 1.2.3.4.

• Note Mac is is little endian so the first sequence appears from the least significant byte to the most significant byte.
• The network does this differently, it is big endian.
• The receiver must know what is the byte order of the source ip address and the byte order of the destination ip address so it can decide the appropriate way to pack the bytes.

Dotted Decimal Notation

...

Notes:

• Here we have this utility function: inet_ntop (network to presentation)
  • Will produce a nicely formatted string, which will take the first byte, second byte and so on. (this is for 32 bits addresses only)

Internet domain names

...

Notes:

• It is a distributed database, which means that not everything in the DNS is in one box or one clustered box, it is all over the internet.
• Below it are Top Level Domains (TLDs)
  • .net, .edu, .goc, .com
• You then look at name like tamu in .edu in order to get .tamu.edu.
  • Some server at TAMU manages this name server for the entire sub-space (it is hosted by a single organization)
  • this entity owns that namespace
• There is a lot of complexity in the DNS, but the only thing we need to know is that it is distributed, not one entity owns the entirety of the DNS namespace.

Querying DNS

...

Notes:

• You can use the dig command to requests DNS lookups
• When you try to resolve a name to an IP address, you are looking for its A record.
  • There are different records for DNS

Example:

> dig linux2.cse.tamu.edu

; <<>> DiG 9.10.6 <<>> linux2.cse.tamu.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53704
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
;; QUESTION SECTION:
;linux2.cse.tamu.edu.           IN      A

;; ANSWER SECTION:
linux2.cse.tamu.edu.    3600    IN      A       128.194.166.90

;; AUTHORITY SECTION:
cse.tamu.edu.           3600    IN      NS      csce-info-grid.net.tamu.edu.
cse.tamu.edu.           3600    IN      NS      wemr-info-dhcp.net.tamu.edu.
cse.tamu.edu.           3600    IN      NS      csce-info-dhcp.net.tamu.edu.

;; ADDITIONAL SECTION:
wemr-info-dhcp.net.tamu.edu. 3600 IN    A       128.194.211.237
csce-info-grid.net.tamu.edu. 3600 IN    A       165.91.16.132
csce-info-dhcp.net.tamu.edu. 3600 IN    A       128.194.169.147
csce-info-dhcp.net.tamu.edu. 3600 IN    A       165.91.16.135

;; Query time: 12 msec
;; SERVER: 128.194.254.1#53(128.194.254.1)
;; WHEN: Wed Apr 08 14:21:12 CDT 2026
;; MSG SIZE  rcvd: 227

• Cashing happens, and it is how we can control how frequent we want to respond

getaddrinfo - name -> ip mapping

...

Notes:

• First argument is the name you are trying to resolve
• The second argument is the name of the service, but we can leave it NULL.
• hints say what type of address you are trying to resolve
• addrinfo
  • I want to resolve this name, but I want to resolve it in this address family
• You get back a linked list of this structure that tells the name resolves to many different IP addresses.

Example:

// Get a list of addrinfo recors
memset (&hints, 0, sizeof(struct addrinfo));
hints.ai_family = AF_INET;    // IPv4 only
hints.ai_socktype = SOCK_STREAM;    // Connections only
if ((rc = getaddrinfo(host, NULL, &hints, &lisp)) != 0) {
	fprintf(stderr, "getaddrinfo error")
	ecit(1);
}

// Walk your rc linked list

getaddrinfo

...

Example:

• Basically this is the call
• Figuring out the why of the arguments might by difficult

Domain Naming System

...

Notes:

• You get back a linked list of addrinfo(), but we are only interested in the address.
• What we are going to do is to cast the pointer to sockaddr

sockaddr = socket address

...

Notes:

• What are only interested in struct in_addr sin_addr; (32 bit IP).

HW1 Q1 - Networking

Problem 1

• Explain the difference between host byte order and network byte order. Why is this distinction important in socket programming?
  • Little endian and Big endian
  • Why is this distinction? We have to agree on a common format, when the receiver gets a bitstream, it can figure out where the address start and where they end, but it needs to know in what order to interpret them. The people who wrote the standard picked big endian.
• Consider a 32-bit integer with the value 0x12345678 on a little-endian machine. What is this value when the bytes are interpreted as if in network byte order? Which function would you use to convert it, and what is the function signature?
  • In big endian it would be: 0x78563412
  • Presentation will give you a byte stream
• If you wanted to store the TCP port number 8080 in a socket address structure for network transmission, how would you prepare it? Show the code using the appropriate byte-order conversion function.
  • You are going to do host to network short
• True or False: You need to convert the IP address returned by inet_pton() to network byte order before placing it in a socket address structure. Explain your answer.

Try all of these questions!

Anatomy of an internet connection

...

Notes:

• Your client is using a port number
• When the server gets the connection, it can say "who is my peer?", where is the connection coming from?
• The client has an IP address and a port number, the way we specify services in our API is by using a 16-bit port number.
  • On the client side it is randomly generated
  • But on the server side, it has to be at a well known port, so that the client can specify it and reach it.