Transcript ntwk6

Client/Server Distributed Systems
240-322, Semester 1, 2005-2006
6. Networking Concepts
 Objectives
– give some background in networking
concepts
– concentrate on the TCP/IP Protocol Suite in
UNIX
240-322 Cli/Serv.: netCon/6
1
Overview
1. The Client-Server Model in UNIX
2. Communication Protocols
3. A Simplified OSI Model
– based on TCP/IP
4. Looking at Datagrams / the Network
240-322 Cli/Serv.: netCon/6
2
1. The Client-Server Model in UNIX
The server:
– provides a service/resource to clients
(e.g. database, printer)
– may be running anywhere on the network
– waits for a service request from a client
(or clients); it is passive
– often started at system boot-up
240-322 Cli/Serv.: netCon/6
continued
3
The client:
– starts the communication with a server;
it is active
– needs to know the server’s ‘address’
– may be running anywhere on the network
240-322 Cli/Serv.: netCon/6
4
1.1. System Services
daemons
– UNIX system-related services that are
always available
– their names often end with ‘d’
e.g.
rlogind, ftpd, sendmail
– many are started at system boot-up by
a ‘super server’, inetd
240-322 Cli/Serv.: netCon/6
5
1.2. Locating a Server
 A server’s
address is in two parts:
– the IP (Internet Protocol) address; a 32-bit
integer. Written in dotted-decimal form:
172.30.0.5
– a port number; a 16-bit integer
the server ‘listens’ for client requests on
that port
240-322 Cli/Serv.: netCon/6
6
IP Addresses
 IP addresses
can also be written in
dotted-name form:
– e.g.
fivedots
fivedots.coe.psu.ac.th
 Most
network functions require the
dotted-decimal form as input.
240-322 Cli/Serv.: netCon/6
7
Converting to dotted-decimal
#include <netdb.h>
struct hostent
*gethostbyname(char *hostname);
 Returns
a struct containing the dotted-decimal
IP address (and other things) corresponding to
the host name
– more details later
240-322 Cli/Serv.: netCon/6
8
Internet Name Servers

gethostbyname() obtains its info. from:
– host details in /etc/hosts
– by sending queries to a name server (named)
on another machine. Its address is usually found
in /etc/resolv.conf
240-322 Cli/Serv.: netCon/6
9
Port Numbers
 The
standard UNIX servers have fixed port
numbers (reserved) between 1 and 1023.
– ftpd listens at port 21
– mail at port 25
– web servers at port 80
 Service
240-322 Cli/Serv.: netCon/6
details are stored in /etc/services
10
Obtaining a Port Number
#include <netdb.h>
struct servent
*getservbyname(char *servname,
char *protoname);
 The
service name is looked up in
/etc/services, and a struct is returned
containing the port number (and other things)
– more details later
240-322 Cli/Serv.: netCon/6
11
1.3. Network Byte Order
 A 16-bit
integer requires two bytes of
storage; a 32-bit integer requires four bytes.
 How
is the integer split across the bytes?
– little endian byte order
e.g. PCs (Intel 80x86, etc), DECs
– big endian byte order
e.g. Macs (Motorola 68000, etc), IBMs
240-322 Cli/Serv.: netCon/6
12
Little Endian Byte Order
 For
a 16-bit integer (2 bytes), such as B34D:
240-322 Cli/Serv.: netCon/6
address
memory
A
4D
low-order byte
A+1
B3
high-order byte
13
Big Endian Byte Order
 For
a 16-bit integer (2 bytes), such as B34D:
address
240-322 Cli/Serv.: netCon/6
memory
A
B3
high-order byte
A+1
4D
low-order byte
14
Standardising
 Most
network protocols (e.g. TCP/IP) use
big-endian format for integers.
 We
must convert all integers (e.g. port
numbers, dotted-decimal addresses) to big
endian format before using them
– usually called network byte order
240-322 Cli/Serv.: netCon/6
15
Converting to big endian
#include <sys/types.h>
#include <netinet/in.h>
u_long htonl(u_long hostlong);
u_short htons(u_short hostshort);
 Converts
the host machine format to
network byte format (big endian):
u_short = 16 bits, u_long = 32 bits
240-322 Cli/Serv.: netCon/6
16
2. Communication Protocols
 How
does a client send a request to a
server?
 Answer:
use a communication protocol
(a set of network commands) understood by
the network and the server.
240-322 Cli/Serv.: netCon/6
continued
17
protocols (e.g. ftp, the Web)
are implemented on top of lower-level
protocols (e.g. TCP, UDP).
 Application
 The
protocol levels are specified in the
ISO OSI model
– ISO = International Standards Organization
– OSI = Open Systems Interconnection
240-322 Cli/Serv.: netCon/6
18
ISO OSI Model
high-level
protocol
low-level
protocol
240-322 Cli/Serv.: netCon/6
7
Application
6
Presentation
5
Session
4
Transport
3
Network
2
Data Link
1
Physical
19
Protocol Suites
 A collection
of related protocols for using
the layers of the OSI model.
 There
–
–
–
–
are many different suites:
TCP/IP
UUCP
XNS (Xerox Network Systems)
NetBIOS (IBM)
240-322 Cli/Serv.: netCon/6
20
TCP/IP
 The
DARPA Internet Protocol Suite:
– DARPA is the research part of the US
Dept. of Defense
– first used in 1981 across 13 sites,
linked by phone lines; developed into
the Internet
– included in BSD UNIX in 1982
240-322 Cli/Serv.: netCon/6
21
TCP/IP Features
 Implemented
on everything
– PCs to supercomputers
 Not
vendor-specific
 Suitable
for LANs and WANs
– scaleable
240-322 Cli/Serv.: netCon/6
22
3. A Simplified OSI Model
 Discussed
by Berson, section 5.4 pp.142-146
– simplified by me!
– read the full version
 A simplification
of the OSI model to four
layers, and using the TCP/IP protocol suite
and ethernet hardware.
240-322 Cli/Serv.: netCon/6
23
Communication between 2 Systems
Application
e.g. FTP client
FTP protocol
Application
e.g. FTP server
Transport
e.g. TCP
TCP protocol
Transport
e.g. TCP
Network
e.g. IP
IP protocol
Network
e.g. IP
Data Link
e.g. ethernet
controller
ethernet frames
Data Link
e.g. ethernet
controller
240-322 Cli/Serv.: netCon/6
The physical network
24
3.1. Data Formatting
 At
a particular layer, the data appears to
cross by the dotted line
– e.g. to the user, the FTP protocol does the work
 In
fact, data is passed down through the
layers, across the physical network, back up
through the layers of the other system.
240-322 Cli/Serv.: netCon/6
continued
25
 As
each layer is descended, the user’s
data is wrapped inside more header (and
footer) information.
 The
headers (and footers) are removed as
the data rises through the layers on the
other system.
240-322 Cli/Serv.: netCon/6
26
Data Encapsulation
application layer
Application data
transport layer
network layer
TCP header
Application data
IP header
TCP header
Application data
IP header
TCP header
Application data
data link layer
ethernet header
240-322 Cli/Serv.: netCon/6
27
3.2. Data Link Layer
 Corresponds
to the OSI physical and data
layers.
 Delivers
frames between two directly
connected machines.
 Network
implementations: ethernet, token
ring, Appletalk, etc.
240-322 Cli/Serv.: netCon/6
28
Simplified Ethernet Frame
Format
Destination Source
Preamble address
address
(64 bits) (48 bits)
(48 bits)
Packet
Data (368
CRC
type
-12,000
(32 bits)
(16 bits) bits)
e.g. IP Datagram
240-322 Cli/Serv.: netCon/6
29
3.3. The Network Layer
 Delivers
datagrams between any two
machines on the Internet
– the IP protocol uses IP addresses
 Machines
may be separated by intervening
gateways/routers.
 User
data may need to be split into several
datagrams due to size limits.
240-322 Cli/Serv.: netCon/6
30
Issues
 Each
datagram is routed independently:
– two datagrams sent from the same source may
travel along different paths
– they may arrive in a different order from the
way they were sent
240-322 Cli/Serv.: netCon/6
continued
31
 A gateway/router
has limited memory:
– it may discard datagrams if too many arrive at
once
– no guarantee that a datagram will arrive at its
destination
240-322 Cli/Serv.: netCon/6
32
Simplified IP Datagram Format
length
Time
To Live
Header
checksum
Options
Source Destination
IP addr IP address
(32 bits). (32 bits)
Data
e.g. TCP
datagram
version
fragmentation
information
240-322 Cli/Serv.: netCon/6
Transport
protocol
for data
33
Fuller Information
 The
previous slide is based on IPv4 which
is starting to be replaced by IPv6:
– key differences: 128-bit addresses, a simpler
header, multicasting, authentication, security
 A good
overview can be found in:
– Appendix A
UNIX Network Programming, Vol. 1
W. Richard Stevens
240-322 Cli/Serv.: netCon/6
34
3.4. The Transport Layer
 Delivers
datagrams between transport
end-points (e.g. machine ports) for any
two machines on the Internet.
 TCP/IP transport
layer protocols:
– UDP: User Datagram Protocol
– TCP: Transmission Control Protocol
240-322 Cli/Serv.: netCon/6
35
3.4.1. UDP
 A connectionless
transport service:
– a user message is split into datagrams and
sent in parts
– there is no (expensive) long-term, dedicated
link needed between the two systems
240-322 Cli/Serv.: netCon/6
continued
36
 Like
the Postal Service:
– UDP datagrams may arrive in any order
– no guarantee that a UDP datagram will arrive
– very close (in functionality) to IP layer
datagrams
240-322 Cli/Serv.: netCon/6
37
Simplified UDP Datagram Format
Source Dest.
port no. port no.
240-322 Cli/Serv.: netCon/6
Length
of data
Checksum
Data for
the application
38
3.4.2. TCP
 A connection-oriented
transport service.
 Client-server
communication can be viewed
as a long-term, dedicated link between
them.
– like the telephone service
– two-way communication is possible
240-322 Cli/Serv.: netCon/6
continued
39
 The
‘dedicated’ link is implemented with
datagrams, but TCP guarantees that:
– TCP datagrams arrive in the order they were
sent
– all TCP datagrams will arrive (none are lost)
240-322 Cli/Serv.: netCon/6
40
TCP Implementation
 How
is reliability and correct ordering
implemented by TCP on top of the IP layer?
240-322 Cli/Serv.: netCon/6
continued
41
 By
using a technique called positive
acknowledgement and retransmission:
– each datagram is numbered
– the TCP layer in the server sends back a
numbered acknowledgement when it gets a
datagram
– the TCP layer in the client resends a datagram
after a certain time if there is no
acknowledgement
240-322 Cli/Serv.: netCon/6
42
Diagram
Events
at sender
(Brown, p.174)
datagram 2
ack 1
datagram 2
resent
datagram 1
Datagram lost
ack 2
Events
at receiver
240-322 Cli/Serv.: netCon/6
43
Improving the Speed
 The
diagram suggests that the sender must
wait for datagram 1 to be acknowledged
before datagram 2 is sent:
– slow and unnecessary
– can send several packets
(up to a limit set by the receiver)
– use the sliding window protocol
240-322 Cli/Serv.: netCon/6
44
Sliding Window Protocol
Byte
stream
1 2 3
window size
4
5
6
7
8
Bytes already sent to receiver
Bytes acknowledged
240-322 Cli/Serv.: netCon/6
Brown p.175
9 10 11 12 13 14 15 16 . . . .
Bytes not sent yet
Bytes not acknowledged yet
45
Notes
 This
mechanism is hidden inside the
implementation of the TCP layer.
– the user only needs to know the interface
functions
 The
IP layer can (and does) support other
transport protocols apart from TCP and
UDP.
240-322 Cli/Serv.: netCon/6
46
Simplified TCP Datagram Format
Sequence
number
Urgent
pointer
Flags
Source Dest.
port no port no
Ack.
number
240-322 Cli/Serv.: netCon/6
Window
size
Options Data
Checksum
47
4. Looking at Datagrams / the Network

tcpdump:
examine datagram headers
– e.g.
tcpdump host fivedots port 80
look at Web server headers

netstat -a
– lists all transport end-points (ports)

snoop
(in Solaris 2.1)
– see “man snoop” and Brown, p.177, 179
240-322 Cli/Serv.: netCon/6
48
 There
are many similar tools for Windows
– search for "packet sniffer" or "network
monitoring" in Google
– many shareware products at places like
http://www.tucows.com
240-322 Cli/Serv.: netCon/6
49