computer networks n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Computer Networks PowerPoint Presentation
Download Presentation
Computer Networks

Loading in 2 Seconds...

play fullscreen
1 / 34

Computer Networks - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

Computer Networks. Application layer. Application Layer. So far Socket programming, Network API Today Application layer functions Specific applications DNS FTP. Application layer functions. Applications

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Computer Networks


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
computer networks

Computer Networks

Application layer

application layer
Application Layer
  • So far
    • Socket programming, Network API
  • Today
    • Application layer functions
    • Specific applications
      • DNS
      • FTP
application layer functions
Application layer functions
  • Applications
    • Implement desired functionality within application protocols when no underlying network service provides support
    • Functionality that is common rolled into libraries and “middleware”
  • Functions
    • Security (S/MIME, PGP)
    • Delivery semantics (multicast overlays, anycast)
    • Reliable data transfer (reliable multicast, reliable UDP)
    • Quality of service (QoS overlays, scheduling)
    • Congestion control (Non-TCP applications)
    • Flow control (Non-TCP applications)
    • Naming (DNS)
    • Routing (overlays)
al specific application protocols
AL: Specific application protocols
  • DNS
    • Background
    • Nutshell description
    • DNS server design
    • DNS client lookups
    • DNS protocol messages
  • FTP
  • HTTP
  • SMTP
al domain name system dns
AL: Domain Name System (DNS)
  • Internet hosts, routers like to use fixed length addresses (numbers)
    • IP address (32 bit) - used for addressing datagrams
  • Humans like to use names
    • www.cse.ogi.edu
    • keywords
  • DNS, keywords, naming protocols
    • Map from IP addresses to names
    • Map from names to IP addresses
al original name to address mapping
AL: Original Name to Address Mapping
  • Flat namespace
    • /etc/hosts
    • SRI kept main copy
    • Downloaded regularly
  • Problems
    • Count of hosts was increasing: machine per domain  machine per user
      • Many more downloads
      • Many more updates
al goals for a new naming system
AL: Goals for a new naming system
  • Implement a wide area distributed database
    • Scalability
    • Decentralized maintenance
    • Robustness, fault-tolerance
    • Global scope
      • Names mean the same thing everywhere
    • Don’t need
      • Atomicity
      • Strong consistency
al goals for a new naming system1
AL: Goals for a new naming system

Why not centralize DNS?

  • Single server with all name-to-IP address mappings
    • single point of failure
    • traffic volume
    • distant centralized database (performance)
    • maintenance
    • doesn’t scale!
al dns domain name system
AL: DNS (Domain Name System)
  • http://www.rfc-editor.org/rfc/rfc1034.txt
  • http://www.rfc-editor.org/rfc/rfc1035.txt
  • distributed database implemented in hierarchy of many name servers
  • decentralized control and management of data
  • application-layer protocol used by hosts, routers, and name servers
    • communicate to resolvenames (address/name translation)
    • core Internet function implemented as application-layer protocol
      • complexity at network’s “edge”
      • compare to phone network naming
al dns nutshell solution
AL: DNS nutshell solution
  • Hierarchical canonical name space
    • www.cse.ogi.edu

root

edu

com

uk

net

org

ca

ogi

bu

mit

ucb

gwu

cse

ece

www

al dns nutshell solution1
AL: DNS nutshell solution
  • Distributed database stores names hierarchically
  • Authoritative name servers store parts of the database
    • Names assigned to authoritative name servers
      • For a host, authority stores that host’s IP address, name
      • Responds to queries for host’s IP address
      • Perform name/address translation for that host’s name
    • Hierarchy organizes authoritative name servers
  • DNS hierarchy
    • Each host has a pointer to a local name server for which to query for unknown names
    • Each local name server knows root of hierarchy
    • Root points to sub-levels, sub-levels point to deeper sub-levels, … , deeper sub-levels point to leaf name server representing authority for unknown name
al dns nutshell figure
AL: DNS nutshell figure

Root name servers:

may not know authoratiative name server

may know intermediate name server: who to contact to find authoritative name server

multiple root name servers for fault-tolerance

local name server

dns.eurecom.fr

intermediate name server

dns.umass.edu

root name server

6

2

3

7

5

4

1

8

authoritative name server

dns.cs.umass.edu

requesting host

surf.eurecom.fr

gaia.cs.umass.edu

al dns server database
AL: DNS server database
  • DB contains tuples called resource records (RRs)
    • RR contains type, class and application data
      • Before types added, only one record type (A)
    • Classes = Internet (IN), Chaosnet (CH), etc.
    • Each class defines types, e.g. for IN:
      • A = address, NS = name server, CNAME = canonical name (for aliasing), HINFO = CPU/OS info, MX = mail exchange, PTR = pointer for reverse mapping of address to name
al dns record types
AL: DNS record types

Resource records (RR) and their types

Type=NS

name is domain (e.g. foo.com)

value is IP address of authoritative name server for this domain

RR format: (name, value, type,ttl)

  • Type=CNAME
    • name is an alias name for some “cannonical” (the real) name
    • value is cannonical name
  • Type=A
    • name is hostname
    • value is IP address
  • Type=MX
    • value is hostname of mailserver associated with name
al dns mx record type
AL: DNS MX record type
  • MX records point to mail exchanger for a name
    • E.g. mail.acm.org is MX for acm.org
  • Addition of MX record type proved to be a challenge
    • How to get mail programs to lookup MX record for mail delivery rather than A record?
    • Needed critical mass of such mailers
  • nslookup example
al dns server database distribution
AL: DNS server database distribution
  • Administrative hierarchy
    • “.” as separator
    • Zone = contiguous section of name space
  • Zones are created by convincing owner node to create/delegate a subzone
    • Each zone contains multiple redundant servers
    • Primary (master) name server updated manually
    • Secondary (redundant) servers updated by zone transfer of name space
    • Provides fault-tolerance within zone
  • Host name to address section
    • Top-level domains  edu, gov, ca, us, etc.
    • Sub-domains = subtrees
    • Human readable name = leaf  root path
al dns client lookups
AL: DNS client lookups
  • Each host has a resolver
    • Typically a library that applications can link gethostbyname()
    • Local name servers hand-configured (e.g. /etc/resolv.conf) or automatically configured (DHCP)
    • Host queries local name server for unknown names
  • Name servers
    • Configured with well-known root servers
      • Currently {a-m}.root-servers.net
    • Local servers
      • Typically do a recursive lookup of distant host names for local hosts
      • Typically answer queries about local zone
al lookup methods
AL: Lookup Methods
  • Recursive queries
    • Server goes out and searches for more info on behalf of the client (recursive)
    • Only returns final answer or “not found”
    • Puts burden of name resolution on contacted name server
    • Heavy load?
      • Root server implosion
  • Iterative
    • Server responds with as much as it knows (i.e. name of server to contact next)
    • “I don’t know this name, but ask this server”
    • Client iteratively queries additional servers
al typical resolution
AL: Typical Resolution
  • Client does recursive request to local name server
  • Local name server does iterative requests to find name
  • Local name server has knowledge of root of name space
  • Steps for resolving www.ogi.edu
    • Application calls gethostbyname()
    • Resolver contacts local name server (S1)
    • S1 queries root server (S2) for (www.ogi.edu)
    • S2 returns NS record for ogi.edu (S3)
    • S1 queries S3 for www.ogi.edu
    • S3 returns A record for www.ogi.edu
  • Can return multiple addresses  what does this mean?
al dns caching
AL: DNS Caching
  • DNS responses are cached
    • Quick response for repeated translations
    • Other queries may reuse some parts of lookup
      • NS records for domains
  • DNS negative queries are also cached
    • Don’t have to repeat past mistakes
    • E.g. misspellings
  • Cached data periodically times out
    • Soft state
    • Lifetime (TTL) of data controlled by owner of data
    • TTL passed with every record
    • TTL affects DNS-based load balancing techniques
  • update/notify mechanisms under design by IETF
    • RFC 2136
    • http://www.ietf.org/html.charters/dnsind-charter.html
al a word about iterated queries and caching
AL: A word about iterated queries and caching
  • Why not do iterative queries from host?
    • Currently
      • Host issues recursive query to local server
      • Local server issues iterative queries subsequently
    • Win2k client
      • Does iterative queries from host
    • Caching implications?
al dns lookup example
AL: DNS Lookup Example

root & edu

DNS server

www.cse.ogi.edu

www.cse.ogi.edu

NS ogi.edu

ogi.edu

DNS server

Local

DNS server

NS cs.ogi.edu

Client

cse.ogi.edu

DNS

server

www=IPaddr

al subsequent lookup example
AL: Subsequent Lookup Example

cse.ogi.edu entry cached

root & edu

DNS server

ftp.cse.ogi.edu

ogi.edu

DNS server

Local

DNS server

Client

ftp.cse.ogi.edu

cse.ogi.edu

DNS

server

ftp=IPaddr

al all recursive dns example
AL: All recursive DNS example

host surf.eurecom.fr wants IP address of gaia.cs.umass.edu

1. Contacts its local DNS server, dns.eurecom.fr

2.dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server, dns.umass.edu, if necessary

local name server

dns.eurecom.fr

root name server

2

4

3

5

authorititive name server

dns.umass.edu

1

6

requesting host

surf.eurecom.fr

gaia.cs.umass.edu

al dns root name servers
AL: DNS root name servers

contacted by local name server that can not resolve name

root name server:

contacts authoritative name server if name mapping not known

gets mapping

returns mapping to local name server

~ dozen root name servers worldwide

nslookup, named example

set iterative

lookup bogus name

al dns nslookup example
AL: DNS/nslookup example
  • Real example using nslookup and named
    • Shows iterative
    • Shows root name servers
    • Shows recursive
    • Shows negative caching
  • nslookup
    • Set iterative
    • Lookup bogus name
    • Get list of root servers
    • Set recursive
    • Lookup same bogus name
    • Get negative response
    • Set iterative
    • Lookup bogus name
    • Get negative response
al dns protocol messages
AL: DNS protocol, messages

DNS protocol :queryand repy messages, both with same message format

msg header

  • identification: 16 bit # for query, repy to query uses same #
  • flags:
    • query or reply
    • recursion desired
    • recursion available
    • reply is authoritative
al dns protocol messages1
AL: DNS protocol, messages

Name, type fields

for a query

RRs in reponse

to query

records for

authoritative servers

additional “helpful”

info that may be used

al dns issues
AL: DNS issues
  • Poor static configuration (root server list)
  • Lack of exponential backoff
  • No centralized caching per site
    • Each machine runs on caching local server
  • UDP used for queries
    • Need reliability  Why not TCP?
al ftp the file transfer protocol
AL: ftp: the file transfer protocol

transfer file to/from remote host

client/server model

client: side that initiates transfer (either to/from remote)

server: remote host

ftp: RFC 959

ftp server: port 21

FTP

user

interface

FTP

client

FTP

server

local file

system

file transfer

user

at host

remote file

system

al ftp separate control data connections
AL: ftp: separate control, data connections

ftp client contacts ftp server at port 21, specifying TCP as transport protocol

two parallel TCP connections opened:

control: exchange commands, responses between client, server.

“out of band control”

data: file data to/from server

ftp server maintains “state”: current directory, earlier authentication

Allows one ftp client to initiate a transfer between two ftp servers

TCP control connection

port 21

TCP data connection

port 20

FTP

client

FTP

server

al ftp commands responses
AL: ftp commands, responses

Sample commands:

sent as ASCII text over control channel

USER username

PASS password

LISTreturn list of file in current directory

RETR filenameretrieves (gets) file

STOR filenamestores (puts) file onto remote host

Sample return codes

status code and phrase (as in http)

331 Username OK, password required

125 data connection already open; transfer starting

425 Can’t open data connection

452 Error writing file

al ftp nat and the port command
AL: ftp, NAT and the PORT command
  • Normal FTP mode
    • Server has port 20, 21 reserved
    • Client initiates control connection by connecting to port 21 on server
    • Client allocates port X for data connection
    • Client passes the data connection port (X) and its IP address in a PORT command to server
    • Server parses PORT command and initiates connection from its own port 20 to the client on port Y
    • What if client is behind a NAT device?
      • NAT must capture outgoing connections destined for port 21
      • What if NAT doesn’t parse PORT command correctly?
      • What if ftp server is running on a different port than 21?
  • http://www.practicallynetworked.com/support/linksys_ftp_port.htm
al ftp nat and the port command1
AL: ftp, NAT, and the PORT command
  • Passive (PASV) mode
    • Client initiates control connection by connecting to port 21 on server
    • Client enables “Passive” mode
    • Server responds with PORT command giving client the IP address and port to use for subsequent data connection (usually port 20, but can be bypassed)
    • Client initiates data connection by connecting to specified port on server
    • Most web browsers do PASV-mode ftp
    • What if server is behind a NAT device?
      • See client issues