======================================================================
CMSC 417-S05     NOTES ON CHAPTER 2: APPLICATION LAYER       SHANKAR

- Telnet, FTP, HTTP, NFS, DNS, Audio, Video,
  P2P (Napster, Gnutella, KaZaa, ...)

- All applications are client-server based
  - App has one or more clients and one or more servers.
- Traditional client-server:
  - servers have well-known ids (names/IP addr/port).
  - clients have dynamic ids
  
- Peer-to-peer:
  - servers and clients are on same hosts
  - dynamic ids (names/IP addr/port)


-----------------------------------------------------------------------
OVERVIEW DIAGRAM for application using TCP 

 clientApp           clientTCP                       serverTCP       serverApp
 --------            ---------                       ---------       ---------
  |                   |                               |               |
  | knows server id   |                               | listening     | listening
  | Issues connect    | new incrn                     |               |
  |                   | a-opening                     | p-opening     |
  |                   |            <-- SYN hndshk --> |               |
  | open              | open                          | open          | open
  |                   |                               |               |
  | tx/rx appData     |            <-- tx/rx msgs --> |               | tx/rx appData
  |                   |                               |               |
  | closeApp          | closing                       | closing       | 
  |                   |            <-- FIN hndshk --> |               |
  | closed            | closed                        | closed        | closed
  |                   |                               |               |
  V                   V                               V               V


Come up with a similar diagram for an application using UDP

-----------------------------------------------------------------------
APPLICATION PROTOCOL
 - Application runs on TCP/UDP.
   TCP just serves as a FIFO channel that can fail.
   UDP just serves as a LRD (loss, reordering, duplication) channel that can fail.
   TCP/UDP does not know about applications, nor do they generate app messages.

-  So the application is a protocol (just like TCP). 
   Defined by:
   - messages
   - actions (upon msg reception, transmission),
   - state of the app entites

----------------------------------------------------------------------
HTTP:
 - Client (web browser)  Server (web server, eg, Apache)
 - uses TCP
 - exchange messages (REQUESTS and RESPONSES)
 - state of app entity:
   - consists of objects (html, gif, mpeg, cgi scripts, ...)
 - objects/entities referenced by URL
 - URL:  protocolId://hostName/objectPathName
   eg,  http://www.cs.umd.edu/classes/417/project.htm 

 - REQUEST messages sent by client
   - get URL
   - http version
   - language
   - ...
 - RESPONSE messages sent by server
   - date
   - status (failed, reason, found, ...)
   - content type, size,
   - content

 - Tracking client
   - try to do it in TCP (not easy over different sites, etc)
   - user/password identifier in each REQ message
   - cookie

----------------------------------------------------------------------
FTP:
 - Client, Server
 - uses TCP
   - control TCP  (open, close, user, passwd, ls, put, get, chdir, ...)
   - separate TCP connection for file transfer

----------------------------------------------------------------------
MAIL:

MAIL CLIENT           MAIL SERVER                  SERVER     CLIENT
     --- SMTP ------>               --- SMTP -->
    <--- POP3 -------
    <--- IMAP -------
    <-- Web-based ---

MAIL SERVER:
 - has SMTP client, SMTP server,
 - has mailboxes for local clients
 - has POP3 (or IMAP or Web-based) server

MAIL CLIENT:
 - has SMTP client, POP3 (or IMAP or Web-based) client

SMTP:
 - sending mail from Client to Server
 - sending mail from Server to Server
 - client-initiated push

POP3 (or IMAP, or Web-based):
 - Client getting mail from Server
 - client initiated pull

----------------------------------------------------------------------
DNS
 - provides mapping of hostname/alias/mailserver --> IP address
 - sometimes used for load balancing, etc.
 - uses UDP
 - used by HTTP, FTP, ..., Sockets, 
 - each dns entity has a dns server and a dns client
 - hierarchy of dns servers

  root servers               o           o    ...        o         o 

  authoritative servers    o o.. o    o o.. o        o o.. o     o o.. o
  local servers            o o.. o    o o.. o        o o.. o     o o.. o

  clients (end hosts)      o o.. o    o o.. o        o o.. o     o o.. o


 - host asks for IP addr of xxx.yyy.edu
   local server provides it, otherwise redirects request to a root server
   root server redirects request to approp authoritative server
 - recursive or interative

 - dns entity is a collection of dns records
   dns record: (name,      value ,             type,  TTL)
                hostname   ip addr              A   
                domain     authServerName       NS
                hostalias  hostCannonicalName   CNAME
                mailserver hostCannonicalName   CNAME

 - DNS message
   - header
     - identifier (for matching response to queries)
     - flags (query/reply, authoritative?, recursion?, ...)
     - number of questions/answers/ ...
   - Data
     - questions (eg, name, type, want ip addr)
     - answers
     - authoritative servers
     - helpful info

----------------------------------------------------------------------
APPLICATION LAYER CONTENT DISTRIBUTION

Idea: Cache/replicate application data on the edge of the Internet
 - reduces application level delays
 - reduce traffic between LAN and Internet
     - improves LAN's access to Internet
     - decreases need to upgrade Internet access BW (costly)

Three ways to do this:
 - Web caching
 - Content Distribution Networks (CDN)
 - Peer-to-peer (P2P) file sharing 

WEB CACHING:
 - Client sends requests to proxy (browser configured to do this)
   If content not found in proxy's cache, proxy gets the stuff.

CDN:
 - Content provider contracts with CDN company.
   Content provider puts content on "original" site
   CDN company puts caches all over the Internet.
 - User request goes to original site, eg, www.orig.com/xx.html.
   But xx.html is only a shell.
   All its "heavy" objects are stored at caches
   and the xx.html only has links to them.
   Eg, object yy.gif is at cache-xx.cdn.com/www.orig.com/yy.gif.
   Thus client gets them from appropriate CDN cache.

   The xx.html page given to client can be tailored to use a cache
   close to the client.

----------------------------------------------------------------------
PEER-TO-PEER FILE SHARING
 - Every end host is a client (seeking content from servers) and
   a server (storing and serving content to clients).
 - End hosts called peers

 - No dedicated servers for holding content.
   Hence issues of redundancy, authentication, etc.

 - Peers have dynamic Internet connectivity and IP addresses.
   So cannot rely on DNS to provide names/IPaddr of peers.

   Require directory of active peers: <active peer, current ip addr>
   Also require directory of content: <peer, content-list>

 - DIRECTORY OF ACTIVE PEERS:
   - Have "bootstrap" servers: always-up, well-known fixed IP addr.
     Bootstrap servers maintain (part of) active peer directory.
   - If bootstrap does not maintain all of active peer directory,
     peers can maintain the rest in some distributed manner
    (eg, hierarchical).

   - Because peers disconnect dynamically without prior warning,
     require mechanism to periodically monitor (ping) peers and
     detect inactive peers and update directory.

 - DIRECTORY OF CONTENT:
   - can be maintained by bootstrap node, by peers, etc.
   - clients can query bootstrap node
   - clients can query peers by
     - flooding
     - limited flooding (radius, hierarchy, ...)

======================================================================