COMP 3400 Networks Lecture 4: Application Layer - DNS, P2P, Sockets
major resource: Computer Networking (4th Edition), Kurose and Ross, Addison Wesley, 2008

[ previous | schedule | next ]

Application Layer service: DNS (Domain Name System)

Overview of DNS

• Major service to translate Internet hostname into IP address
• Can also resolve aliases, allowing user to for instance specify "hotmail.com" as either the URL in a web request or in someone's email address (george@hotmail.com) even though these requests are handled by different servers
• Its main clients are other application layer protocols such as HTTP and SMTP, or sockets acting on their behalf.
• Supported by distributed database and hierarchy of DNS servers
• Domain names and numbers are controlled by ICANN, the Internet Corporation for Assigned Names and Numbers. See www.icann.org.
• Foundation RFCs include RFC 1034 and RFC 1035, updated by several subsequent
• Client-server communication using UDP over port 53
• Can use this service from command prompt: nslookup

  Z:\>nslookup www.otterbein.edu
  Server:  ns1.otterbein.edu
  Address:  205.133.226.154
  
  Name:    occardinal.otterbein.edu
  Address:  205.133.226.114
  Aliases:  www.otterbein.edu
  
  Z:\>

• A number of web-based nslookup services, e.g. www.kloth.net/services/nslookup.php

DNS network organization

• Service must be distributed because of its database is so large and dynamic
• Organization is a very shallow but wide tree (few levels, many siblings)
• Root Servers at the root of the tree. There are currently 13, each replicated
• TLD Servers (Top Level Domain) just below. These represent the last component of a server's name (organization and country codes such as com, org, fr, us, jp, and so forth)
• Authoritative Servers provided by each organization to hold DNS database entries for its servers and to perform DNS functions concerning them
• Every host has the IP address of a local server to which the host will request DNS service
• The process is addressed next.

Pure Recursive DNS query

• Each client in request chain issues DNS request on behalf of original requester and gets definitive response - resource record(s) or error.
• Request travels from local server up the hierarchy and back down to authoritative server, then recurses back to local server
• Example: A worst case recursive query for “www.pitt.edu” is this:
  1. Host asks local server for IP address
  2. Local server doesn't know but asks a root server
  3. Root server notes the "edu" and asks the TLD server for "edu" domain
  4. TLD server for "edu" doesn’t know but asks authoritative server for "pitt.edu".
  5. Authoritative server for "pitt.edu" retrieves the entry from its DNS database, packages it into a message, and returns it to the TLD server
  6. TLD server relays the response message to the root server
  7. Root server relays the response message to the local server
  8. Local server relays the response to the original host
• Note the large amount of network traffic and demand on the root server. We'll address both issues.

Iterative DNS query

• All requests are made by local server and all responses go directly to the local server.
• Response will contain either the DNS record or identity of another server to ask
• Example: A worst case iterative query for “www.pitt.edu” is this:
  1. Host asks local server for IP address
  2. Local server doesn't know but asks a root server
  3. Root server doesn't know but responds to local server with the address of a TLD server for "edu"
  4. Local server asks the TLD server for "edu"
  5. TLD server for "edu" doesn’t know but responds to local server with the address of the authoritative server for "pitt.edu"
  6. Local server asks the authoritative server for "pitt.edu"
  7. Authoritative server for "pitt.edu" retrieves the record from its DNS database, packages it into a message, and returns it to the local server
  8. Local server relays the response to the original host
• Same number of messages, but less demand on the root and TLD servers since they don't have to relay responses.
• Note this is not purely iterative, since there is no response to the original requesting host until the end

Caching is Critical to DNS Performance

• Response containing an answer (DNS record) is cached by recipient
• More precisely, DNS record containing name-to-IP mapping is cached (more below)
• If multiple requests for same server are made over a short period of time, all but the first will be handled by local server
• Caching obviously reduces network traffic, reduces DNS server loads, reduces response time
• Local server commonly caches TLD server addresses so it can by-pass root server totally

DNS Security and Resilience are Paramount

• DNS service is used by all applications that require name-to-IP translation
• What would happen if root servers were brought down by denial-of-service, or infected?
• What if the DNS system, or any of its servers, were poisoned to give bogus responses (pharming)?
• DNS is heavily fortified and has survived all attacks so far with little negative consequence

Alternative Root Servers

• There are renegade "alternative root servers" out there, supporting ICANN’s TLDs plus a slew of others.
• OpenNIC is a prominent one, see www.opennicproject.org
• This is not very difficult to implement, but ICANN does not like it one bit...
• For more info, see for example the Wikipedia entry for Alternative DNS root (how authoritative is Wikipedia?)

Peer-To-Peer (P2P) Applications and Protocols

Intro and Major Issues

• A "leaderless" architecture; all participants are peers
• No always-on, well-known server
• Major advantages
  • Resilient (no single point of failure)
  • Scalable (no single bottleneck as demand rises)
  • Greater freedom (not at mercy of server)
• Major disadvantages
  • More network overhead
  • potentially less trustworthy (have to depend on peers)
  • anything else?
• Major applications based on P2P architecture
  • File distribution - such as BitTorrent
  • Instant messaging
  • Internet Telephony (VoIP) - such as Skype
• Scalability example: distributing a file of size F
  • client-server with 1 server and N clients scales linearly, total server time N * F
  • P2P with N requesting peers scales logarithmically, original peer time is F then redistributed in parallel by receiving peers
• Major P2P issues include
  • Joining a network
  • Finding what you need
  • Downloading
  • Contributing to the network by uploading
  • Leaving the network

Sockets Programming for TCP

Inter-process communication through sockets

• process is running program
• How does a client process communicate with server process to make request?
• How does a server process communicate with client process to give response?
• Both happen through sockets, the API to the transport layer
• Sockets are message-passing mechanism between application and transport layers
• Also applies to P2P because it is fundamentally client-server-based, client initiating request and server responding
• Sockets API (library) is fairly easy to use in C, C++, Java and other languages
• Java provides high-level support (more later)
• How to address the process at the other end?
• IP address (32 bits, 128 with IPv6), network layer, identifies machine
• port number integer that identifies the process
• There could be several Internet processes running at that IP address
• Each service has standard port number, so sender knows what to use (e.g. 80 for HTTP)

Overview of Sockets

• API between application and transport layers
• (rephrased) Your application program uses them to communicate with network and OS
• Internet sockets come in two flavors: TCP-based and UDP-based
• We'll focus on TCP:
  • Guaranteed sequenced and error-free delivery
  • Connection-oriented stream service
  • Basic protocol for TCP-based sockets
    • 3-way handshake to establish client-server connection
    • 2-way communication through connection socket
    • close connection socket when finished
• Each service and socket communicates over a designated port
• Client and server each follow distinct protocol

Client protocol (typical):

1. Request socket connection, wait for confirmation
2. Send request over socket
3. Wait for and receive server reply over socket
4. Repeat send-receive cycle (steps 2 and 3) as required by application protocol
5. Close socket connection

Server protocol (typical):

1. Create a server socket to handle incoming connection requests
2. Wait for incoming connection requests
3. When request arrives, create a connection socket for communication (this leaves server socket free to accept additional connection requests)
4. Receive client request over connection socket
5. Send reply to client over connection socket
6. Repeat receive-send cycle (steps 4 and 5) as required by application protocol
7. Close connection socket

Simple Example Java client and server

• We will demo and examine simple Java application that uses TCP sockets
• The java.net package provides great library support for sockets

import java.io.*; 
import java.net.*; 
class TCPClient { 
    public static void main(String argv[]) throws Exception   { 
        String sentence; 
        String modifiedSentence; 

        BufferedReader inFromUser = 
            new BufferedReader(new InputStreamReader(System.in)); 
        Socket clientSocket = new Socket("PSandersonLT12.otterbein.edu", 6789); 
        DataOutputStream outToServer = 
            new DataOutputStream(clientSocket.getOutputStream()); 
        BufferedReader inFromServer = 
            new BufferedReader(new
            InputStreamReader(clientSocket.getInputStream())); 
        sentence = inFromUser.readLine(); 
        outToServer.writeBytes(sentence + '\n'); 
        modifiedSentence = inFromServer.readLine(); 
        System.out.println("FROM SERVER: " + modifiedSentence); 
        clientSocket.close();         
    } 
} 

import java.io.*; 
import java.net.*; 
class TCPServer { 
  public static void main(String argv[]) throws Exception  { 
      String clientSentence; 
      String capitalizedSentence; 
      ServerSocket welcomeSocket = new ServerSocket(6789); 
      while(true) { 
           Socket connectionSocket = welcomeSocket.accept(); 
           BufferedReader inFromClient = 
              new BufferedReader(new
              InputStreamReader(connectionSocket.getInputStream())); 
           DataOutputStream  outToClient = 
              new DataOutputStream(connectionSocket.getOutputStream()); 
           clientSentence = inFromClient.readLine(); 
           capitalizedSentence = clientSentence.toUpperCase() + '\n'; 
           outToClient.writeBytes(capitalizedSentence); 
        } 
    } 
}