We are now half-way done with our Computer Networking class, so we took our midterm. This is only the second time that our cohort has had to take a proctored exam at an exact time with everyone logged into Zoom with our cameras on. It’s a strange experience that I don’t prefer to the alternative of having a harder task-based exam with a larger window of time for completion.

Because we had the midterm, there was not a lot of new content covered. We went back to the second chapter of our textbook to review a section we had skipped over on socket programming, which I found interesting. I hope we will have an opportunity to complete an assignment that has to deal with socket programming.

There are some differences when programming an application that uses TCP versus UCP since TCP is connection oriented and UCP is connectionless. However, one commonality is that both protocols are “open” and specified in the RFC protocol standard. This means that independent developers can easily work on implementing a server or a client program that can work together. This also means that the server/client programs would make use of the well-known port number established for UCP or TCP.

This week we delved into the second layer of the Internet architecture burrito: the transport layer. However, it was impossible not to at least brush upon the network layer as well because of their tightly knit relationship. Transport-layer protocols (TCP and UDP) provide logical communication between application processes running on different hosts — but they’re domain is the host itself. The communication between hosts is the domain of the network layer.

During week 2 of our computer networking course, we focused on the application layer (the top layer of the five layer protocol stack that comprises Internet architecture).

In the beginning section of our reading, we were given an overview of common application layer protocols and the underlying transport layer–either TCP or UDP–associated with each. Most common application layer protocols seem to be built on top of TCP (transmission control protocol) rather than UDP (user datagram protocol).

What transport layer protocol should my app be built over?

TCP is a popular choice because it provides reliable data transfer service, providing error checking to ensure all packets of a message are received and assembled in the correct order. However, because TCP is more complex than UDP, it is more likely to suffer from latency. In some applications (e.g. telephony or media streaming), some data loss is tolerable when it means less latency. Therefore, such applications may be built over UDP rather than TCP. However, when an application cannot tolerate data loss (e.g. text messaging or file transfer) but can tolerate some latency, that application may be built over TCP.

Pushy protocols give and pully ones receive

We also learned the that application protocols can be classified as pull or push. For instance, HTTP is a pull protocol because a client uses HTTP to retrieve data from a web server. SMTP, on the other hand, is a push protocol because email clients push out data to a receiving email sever. This gives context to why we use these verbs in git.

Sorry, Mario. Your IP is in another DNS Castle

We also covered Domain Name Services (DNS). While I previously understood the function of DNS, that there are many DNS servers, and that not every one had an exhaustive list of IP addresses to map on to a given domain name, I was unaware of the extent to which DNS severs were categorized hierarchically and that requests can either be resolved iteratively or recursively.

P2P Architecture

One of my favorite parts of this week’s reading was about Peer-to-Peer (P2P) architecture because it made me nostalgic for when the architecture was first popularized when I was in high school circa 1999. During this time, many P2P media sharing applications were born–Napster, Morpheus, Kazaa, SoulSeek. This method of file sharing was revolutionary because anyone could be a seed (server) or a leech (client) at the same time and you did not have to have the entire file to serve chunks of data to others. P2P architecture scales much better than server-client architecture as the number of hosts increase. This is because every host becomes a server as soon as they successfully fetch some part of the target file.

After a short summer break, we have begun a new class in Computer Networking. I think this course will really demystify some of the concepts we glossed over in Internet Programming, particularly when it comes to making design decisions in creating a web API.

This week, we read the first chapter of Computer Networking: A Top-Down Approach (Kurose and Ross, 2016), which included a broad overview of the five-layer Internet architecture: