Review of Previous Lecture

1
Review of Previous Lecture

• Principles of app layer protocols
• clients and servers
• app requirements
• Web and HTTP
• FTP

2
Announcement

• All got partners and IP addresses ?
• Should complete at least part I by the end of
  this week
• Networking research project available (preferably
  with OS background)

3
Outline

• Electronic Mail SMTP, POP3, IMAP
• DNS
• Socket programming with TCP

4
Electronic Mail

• Three major components
• user agents
• mail servers
• simple mail transfer protocol SMTP
• User Agent
• a.k.a. mail reader
• composing, editing, reading mail messages
• e.g., Eudora, Outlook, elm, Netscape Messenger
• outgoing, incoming messages stored on server

5
Electronic Mail mail servers

• Mail Servers
• mailbox contains incoming messages for user
• message queue of outgoing (to be sent) mail
  messages
• SMTP protocol between mail servers to send email
  messages
• client sending mail server
• server receiving mail server

6
Electronic Mail SMTP RFC 2821

• uses TCP to reliably transfer email message from
  client to server, port 25
• direct transfer sending server to receiving
  server
• three phases of transfer
• handshaking (greeting)
• transfer of messages
• closure
• command/response interaction
• commands ASCII text
• response status code and phrase
• messages must be in 7-bit ASCII

7
Scenario Alice sends message to Bob

• 4) SMTP client sends Alices message over the TCP
  connection
• 5) Bobs mail server places the message in Bobs
  mailbox
• 6) Bob invokes his user agent to read message

• 1) Alice uses UA to compose message and to
  bob_at_someschool.edu
• 2) Alices UA sends message to her mail server
  message placed in message queue
• 3) Client side of SMTP opens TCP connection with
  Bobs mail server

1
2
6
3
4
5
8
SMTP final words

• Comparison with HTTP
• HTTP pull
• SMTP push
• both have ASCII command/response interaction,
  status codes

• SMTP uses persistent connections
• SMTP requires message (header body) to be in
  7-bit ASCII
• SMTP server uses CRLF.CRLF to determine end of
  message

9
Mail message format

• SMTP protocol for exchanging email msgs
• RFC 822 standard for text message format
• header lines, e.g.,
• To
• From
• Subject
• different from SMTP commands!
• body
• the message, ASCII characters only

header
blank line
body
10
Message format multimedia extensions

• MIME multimedia mail extension, RFC 2045, 2056
• additional lines in msg header declare MIME
  content type

MIME version
method used to encode data
multimedia data type, subtype, parameter
declaration
encoded data
11
MIME typesContent-Type type/subtype parameters

• Seven top-level types defined
• Text
• example subtypes plain, html
• Image
• example subtypes jpeg, gif
• Application
• other data that must be processed by reader
  before viewable
• example subtypes msword, octet-stream

12
Mail access protocols
SMTP
access protocol
receivers mail server

• SMTP delivery/storage to receivers server
• Mail access protocol retrieval from server
• POP Post Office Protocol RFC 1939
• authorization (agent server) and download
• IMAP Internet Mail Access Protocol RFC 1730
• more features (more complex)
• manipulation of stored msgs on server
• HTTP Hotmail , Yahoo! Mail, etc.

13
Outline

• Electronic Mail SMTP, POP3, IMAP
• DNS
• Socket programming with TCP

14
DNS Domain Name System

• Domain Name System
• distributed database implemented in hierarchy of
  many name servers
• application-layer protocol host, routers, name
  servers to communicate to resolve names
  (address/name translation)
• note core Internet function, implemented as
  application-layer protocol
• complexity at networks edge
• Run on UDP, port 53

• People many identifiers
• SSN, name, passport
• Internet hosts, routers
• IP address (32 bit) - used for addressing
  datagrams
• name, e.g., home1.cs.nwu.edu - used by humans
• Q map between IP addresses and name ?

15
DNS name servers

• no server has all name-to-IP address mappings
• local name servers
• each ISP, company has local (default) name server
• host DNS query first goes to local name server
• authoritative name server
• for a host stores that hosts IP address, name
• can perform name/address translation for that
  hosts name

• Why not centralize DNS?
• single point of failure
• traffic volume
• distant centralized database
• maintenance
• doesnt scale!

16
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

13 root name servers worldwide
17
Simple DNS example
root name server

• host surf.eurecom.fr wants IP address of
  www.cs.nwu.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

2
4
3
5
authorititive name server dns.nwu.edu
1
6
requesting host surf.eurecom.fr
www.cs.nwu.edu
18
DNS example
root name server

• Root name server
• may not know authoritative name server
• may know intermediate name server who to contact
  to find authoritative name server

6
2
3
7
5
4
1
8
authoritative name server dns.cs.nwu.edu
requesting host surf.eurecom.fr
www.cs.nwu.edu
19
DNS iterated queries
root name server

• recursive query
• puts burden of name resolution on contacted name
  server
• heavy load?
• iterated query
• contacted server replies with name of server to
  contact
• I dont know this name, but ask this server

iterated query
2
3
4
7
5
6
1
8
authoritative name server dns.cs.umass.edu
requesting host surf.eurecom.fr
gaia.cs.umass.edu
20
DNS caching and updating records

• once (any) name server learns mapping, it caches
  mapping
• cache entries timeout (disappear) after some time
• update/notify mechanisms under design by IETF
• RFC 2136
• http//www.ietf.org/html.charters/dnsind-charter.h
  tml

21
DNS records

• DNS distributed db storing resource records (RR)

• TypeA
• name is hostname
• value is IP address

• TypeCNAME
• name is alias name for some cannonical (the
  real) name
• www.ibm.com is really
• servereast.backup2.ibm.com
• value is cannonical name

• TypeNS
• name is domain (e.g. foo.com)
• value is IP address of authoritative name server
  for this domain

• TypeMX
• value is name of mailserver associated with name

22
Outline

• Electronic Mail SMTP, POP3, IMAP
• DNS
• Socket programming with TCP

23
Socket programming
Goal learn how to build client/server
application that communicate using sockets

• Socket API
• introduced in BSD4.1 UNIX, 1981
• explicitly created, used, released by apps
• two types of transport service via socket API
• unreliable datagram
• reliable, byte stream

24
Socket-programming using TCP

• Socket a door between application process and
  end-end-transport protocol (UCP or TCP)
• TCP service reliable transfer of bytes from one
  process to another

controlled by application developer
controlled by application developer
controlled by operating system
controlled by operating system
internet
host or server
host or server
25
Socket programming with TCP

• Client must contact server
• server process must first be running
• server must have created socket (door) that
  welcomes clients contact
• Client contacts server by
• creating client-local TCP socket
• specifying IP address, port number of server
  process
• When client creates socket client TCP
  establishes connection to server TCP

• When contacted by client, server TCP creates new
  socket for server process to communicate with
  client
• allows server to talk with multiple clients
• source port numbers used to distinguish clients
  (more in Chap 3)

26
TCP Server
socket()
bind()
Well-known port
TCP Client
listen()
Socket()
accept()
blocks until connection from client
connect()
Connection establishment
Data(request)
write()
read()
process request
Data(reply)
write()
read()
close()
End-of-file notification
read()
close()
27
Client high level view
Create a socket
Setup the server address
Connect to the server
Read/write data
Shutdown connection
28
Creating a Socket

• int socket(int family,int type,int proto)
• family specifies the protocol family (PF_INET for
  TCP/IP).
• type specifies the type of service (SOCK_STREAM,
  SOCK_DGRAM).
• protocol specifies the specific protocol (usually
  0, which means the default).

29
socket()

• The socket() system call returns a socket
  descriptor (small integer) or -1 on error.
• socket() allocates resources needed for a
  communication endpoint - but it does not deal
  with endpoint addressing.
• Sockets API is generic.
• TCP/IP requires an IP address and a port number
  for each endpoint address.
• Other protocol suites (families) may use other
  schemes.

30
Necessary Background Information POSIX data
types

• int8_t signed 8bit int
• uint8_t unsigned 8 bit int
• int16_t signed 16 bit int
• uint16_t unsigned 16 bit int
• int32_t signed 32 bit int
• uint32_t unsigned 32 bit int
• u_char, u_short, u_int, u_long

31
More POSIX data types

• sa_family_t address family
• socklen_t length of struct
• in_addr_t IPv4 address
• in_port_t IP port number

32
Address and port byte-ordering

• Address and port are stored as integers
• u_short sin_port (16 bit)
• in_addr sin_addr (32 bit)

struct in_addr u_long s_addr

• Problem
• different machines / OSs use different word
  orderings
• little-endian lower bytes first
• big-endian higher bytes first
• these machines may communicate with one another
  over the network

Big-Endian machine
Little-Endian machine
12.40.119.128
128.119.40.12
WRONG!!!
33
Solution Network Byte-Ordering

• Defs
• Host Byte-Ordering the byte ordering used by a
  host (big or little)
• Network Byte-Ordering the byte ordering used by
  the network always big-endian
• Any words sent through the network should be
  converted to Network Byte-Order prior to
  transmission (and back to Host Byte-Order once
  received)
• Q should the socket perform the conversion
  automatically?

• Q Given big-endian machines dont need
  conversion routines and little-endian machines
  do, how do we avoid writing two versions of code?

34
Network Byte Order Functions

• u_long htonl(u_long x)
• u_short htons(u_short x)

• u_long ntohl(u_long x)
• u_short ntohs(u_short x)

• On big-endian machines, these routines do nothing
• On little-endian machines, they reverse the byte
  order
• Same code would have worked regardless of
  endian-ness of the two machines

Big-Endian machine
Little-Endian machine
128.119.40.12
128.119.40.12
35
Network Byte Order Functions

• h host byte order n network byte
  order
• s short (16bit) l long
  (32bit)
• uint16_t htons(uint16_t)
• uint16_t ntohs(uint_16_t)
• uint32_t htonl(uint32_t)
• uint32_t ntohl(uint32_t)

36
connect()

• int connect( int sockfd,
• const struct sockaddr server,
• socklen_t addrlen)
• sockfd is an already created TCP socket.
• server contains the address of the server (IP
  Address and TCP port number)
• connect() returns 0 if OK, -1 on error

37

• int connect_ socket( char hostname, int port)
• int sock
• struct sockaddr_in sin
• struct hostent host
• sock socket( AF_ INET, SOCK_ STREAM, 0)
• if (sock -1)
• return sock
• host gethostbyname( hostname)
• if (host NULL)
• close( sock)
• return -1
• memset ( sin, 0, sizeof( sin))
• sin. sin_ family AF_ INET
• sin. sin_ port htons( port)
• sin. sin_ addr. s_ addr ( unsigned long )
  host- h_ addr_ list 0
• if (connect( sock, (struct sockaddr ) sin,
  sizeof( sin)) ! 0)
• close (sock)
• return -1