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.