Computer

Networks
(IN 2510)

Dr. C. Amalraj
13/05/2016
The University of Moratuwa
amalraj@uom.lk
Lecture 12:
Data-link Layer
Data-Link
Layer
Position of the data-link layer
Data link layer duties
LLC and MAC sublayers
IEEE standards for LANs
Error Detection
and Correction
Error Detection and Correction
Data can be corrupted during
transmission. For reliable communication,
error must be detected and corrected
Error Detection and Correction are
implemented either at the data link
layer and at the transport layer of the
OSI model
Type of Errors
Type of Errors(contd)
Single-Bit Error
~ is when only one bit in the data unit has changed
Type of Errors(contd)

Multiple-Bit Error
~ is when two or more nonconsecutive bits in the
data unit have changed(ex : ASCII B - ASCII LF)
Type of Errors(contd)
Burst Error
~ means that 2 or more consecutive bits in the data
unit have changed
Detection
Error detection uses the concept of redundancy,
which means adding extra bits for detecting
errors at the destination
Detection(contd)
Redundancy
Detection(contd)
Detection(contd)
Parity Check
A parity bit is added to every data unit so that the total number of
1s (including the parity bit) becomes even for even-parity check or
odd for odd-parity check
Simple parity check
Detection - Examples

Example 1
Suppose the sender wants to send the word world. In
ASCII the five characters are coded as
1110111 1101111 1110010 1101100 1100100
The following shows the actual bits sent
11101110 11011110 11100100 11011000 11001001
 Detection - Examples

Example 2

Now suppose the word world in Example 1 is received by

the receiver without being corrupted in transmission.
11101110 11011110 11100100 11011000 11001001
The receiver counts the 1s in each character and comes up
with even numbers (6, 6, 4, 4, 4). The data are accepted.
 Detection - Examples
Example 3
Now suppose the word world in Example 1 is corrupted
during transmission.
11111110 11011110 11101100 11011000 11001001
The receiver counts the 1s in each character and comes up
with even and odd numbers (7, 6, 5, 4, 4). The receiver
knows that the data are corrupted, discards them, and asks
for retransmission.
Two Dimensional Parity Check
 Detection - Examples
Example 4
Suppose the following block is sent:
10101001 00111001 11011101 11100111 10101010
However, it is hit by a burst noise of length 8, and some bits
are corrupted.
10100011 10001001 11011101 11100111 10101010
When the receiver checks the parity bits, some of the bits do
not follow the even-parity rule and the whole block is
discarded.
10100011 10001001 11011101 11100111 10101010
Error Detection Methods

Vertical Redundancy Check (VRC)

Append a single bit at the end of data block such that
the number of ones is even
Even Parity (odd parity is similar)
0110011 01100110
0110001 01100011
VRC is also known as Parity Check
Performance:
Detects all odd-number errors in a data block
Error Detection Methods
Longitudinal Redundancy Check (LRC)
Organize data into a table and create a parity for each
column

11100111 11011101 00111001 10101001

11100111
11011101
00111001
10101001
10101010

11100111 11011101 00111001 10101001 10101010

Original Data LRC
 Detection(contd)
CRC(Cyclic Redundancy Check)
~ is based on binary division.
Cyclic Redundancy Check
Sending
1. Multiply M(x) by xn
2. Divide xnM(x) by P(x)
3. Ignore the quotient and keep the reminder C(x)
4. Form and send F(x) = xnM(x)+C(x)

Receiving
1. Receive F(x)
2. Divide F(x) by P(x)
3. Accept if remainder is 0, reject otherwise
Example
Send
Receive
M(x) = 110011 x5+x4+x+1 (6 bits)
P(x) = 11001 x4+x3+1 (5 bits, n = 4) 11001 1100111001
4 bits of redundancy 11001
Form xnM(x) 110011 0000 11001
x9+x8+x5+x4
11001
Divide xnM(x) by P(x) to find C(x)
00000

100001
No remainder
11001 1100110000 Accept
11001
10000
11001
1001 = C(x)
Send the block 110011 1001
 Detection(contd)
CRC generator
~ uses modular-2 division.

Binary Division
in a
CRC Generator
Detection(contd)
Binary Division
in a
CRC Checker
Detection(contd)

Polynomials
CRC generator(divisor) is most often represented not
as a string of 1s and 0s, but as an algebraic polynomial.
Detection(contd)
A polynomial representing a divisor
Detection(contd)
Standard polynomials
Detection(contd)

Checksum
~ used by the higher layer protocols
~ is based on the concept of redundancy(VRC,
LRC, CRC .)
Detection(contd)
Checksum Generator
Detection(contd)

To create the checksum the sender does the

following:
The unit is divided into K sections, each of n bits.
Section 1 and 2 are added together using ones
complement.
Section 3 is added to the result of the previous step.
Section 4 is added to the result of the previous step.
The process repeats until section k is added to the
result of the previous step.
The final result is complemented to make the
checksum.
Detection(contd)

data unit and checksum

Detection(contd) Eg. IP Header
Detection(contd)

at a sender
Original data : 10101001 00111001
10101001
00111001
--------------
11100010 Sum
00011101 Checksum
10101001 00111001 00011101 data sent
Detection(contd)

Example ( at a receiver)
Received data : 10101001 00111001 00011101
10101001
00111001
00011101
---------------
11111111 Sum
00000000 Complement
Web and
HTTP
Web and HTTP
First some jargon
Web page consists of objects
Object can be HTML file, JPEG image, Java applet,
audio file,
Web page consists of base HTML-file which
includes several referenced objects
Each object is addressable by a URL
Example URL:

www.someschool.edu/someDept/pic.gif
host name path name
 HTTP overview

HTTP: hypertext transfer protocol

Webs application layer protocol
client/server model PC running
client: browser that requests, Explorer

receives, displays Web

objects
server: Web server sends Server
running
objects in response to Apache Web
requests server

HTTP 1.0: RFC 1945 Mac running

HTTP 1.1: RFC 2068 Navigator
HTTP overview (cont.)
Uses TCP:
client initiates TCP connection
(creates socket) to server, port
80
server accepts TCP connection
from client
HTTP messages (application-
layer protocol messages)
exchanged between browser
(HTTP client) and Web server
(HTTP server)
TCP connection closed
HTTP is stateless
server maintains no
information about past
client requests
aside
Protocols that maintain
state are complex!
past history (state) must
be maintained
if server/client crashes,
their views of state may
be inconsistent, must be
reconciled
HTTP connections
Nonpersistent HTTP Persistent HTTP
At most one object is Multiple objects can be
sent over a TCP sent over single TCP
connection. connection between client
HTTP/1.0 uses and server.
nonpersistent HTTP HTTP/1.1 uses persistent
connections in default
mode
 Nonpersistent HTTP
Suppose user enters URL
www.someSchool.edu/someDepartment/home.index
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.someSchool.edu on port 80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
time
(contains text,
references to 10
jpeg images)
1b. HTTP server at host
www.someSchool.edu waiting
for TCP connection at port 80.
accepts connection, notifying
client
3. HTTP server receives request
message, forms response
message containing requested
object, and sends message
into its socket
 Nonpersistent HTTP (cont.)

4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

time
6. Steps 1-5 repeated for each
of 10 jpeg objects
Response time modeling
Definition of RTT: time to send
a small packet to travel from
client to server and back.
initiate TCP
Response time: connection
one RTT to initiate TCP RTT
connection request
file
one RTT for HTTP request RTT
time to
transmit
and first few bytes of HTTP file
response to return file
received
file transmission time
total = 2RTT+transmit time time time
Persistent HTTP
Nonpersistent HTTP issues:
requires at least 2 RTTs per
object
OS must work and allocate host
resources for each TCP
connection
but browsers often open parallel
TCP connections to fetch
referenced objects
Persistent HTTP
server leaves connection open
after sending response
subsequent HTTP messages
between same client/server are
sent over connection
Persistent without pipelining:
client issues new request only
when previous response has
been received
at least one RTT for each
referenced object
Persistent with pipelining:
default in HTTP/1.1
client sends requests as soon as
it encounters a referenced
object
may be as little as one RTT for
all the referenced objects
HTTP request message
two types of HTTP messages: request, response
HTTP request message:
ASCII (human-readable format)

request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return, (extra carriage return, line feed)

line feed
indicates end
of message
HTTP request message: general format
Uploading form input
Post method:
Web page often includes form input
Input is uploaded to server in entity body

URL method:
Uses GET method
Input is uploaded in URL field of request line:

www.somesite.com/animalsearch?monkeys&banana
Method types
HTTP/1.0 HTTP/1.1
GET GET, POST, HEAD
POST PUT
HEAD uploads file in entity body
to path specified in URL
asks server to leave
field
requested object out of
response DELETE
deletes file specified in the
URL field
HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
header
Last-Modified: Mon, 22 Jun 1998 ...
lines
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file
HTTP response status codes
In first line in server->client response message.
A few sample codes:

200 OK
request succeeded, requested object later in this message
301 Moved Permanently
requested object moved, new location specified later in this
message (Location:)
400 Bad Request
request message not understood by server
404 Not Found
requested document not found on this server
505 HTTP Version Not Supported
 Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 Opens TCP connection to port 80
(default HTTP server port) at cis.poly.edu.
Anything typed in sent
to port 80 at cis.poly.edu

2. Type in a GET HTTP request:

GET /~ross/ HTTP/1.1 By typing this in (hit carriage

Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server

3. Look at response message sent by HTTP server!

User-server state: cookies
Many major Web sites use
cookies
Four components:
1) cookie header line in the
HTTP response message
2) cookie header line in HTTP
request message
3) cookie file kept on users
host and managed by users
browser
4) back-end database at Web
site
Example:
Susan access Internet
always from same PC
She visits a specific
e-commerce site for first
time
When initial HTTP
requests arrives at site, site
creates a unique ID and
creates an entry in backend
database for ID
 Cookies: keeping state (cont.)

client server

Cookie file usual http request msg server

usual http response + creates ID
ebay: 8734 Set-cookie: 1678 1678 for user

Cookie file
usual http request msg
amazon: 1678 cookie: 1678 cookie-
ebay: 8734 specific
usual http response msg action
one week later:

Cookie file usual http request msg

cookie-
cookie: 1678
amazon: 1678 spectific
ebay: 8734 usual http response msg action
Cookies (continued)
aside
What cookies can bring: Cookies and privacy:
authorization cookies permit sites to
learn a lot about you
shopping carts you may supply name
recommendations and e-mail to sites
user session state (Web search engines use
e-mail) redirection & cookies
to learn yet more
advertising companies
obtain info across
sites
Web caches (proxy server)
Goal: satisfy client request without involving origin server

user sets browser: Web origin

accesses via cache server

browser sends all HTTP Proxy

requests to cache server
object in cache: cache client
returns object
else cache requests object
from origin server, then
returns object to client

client
origin
server
More about Web caching
Cache acts as both client and
server
Typically cache is installed by
ISP (university, company,
residential ISP)
Why Web caching?
Reduce response time for
client request.
Reduce traffic on an
institutions access link.
Internet dense with caches
enables poor content
providers to effectively deliver
content (but so does P2P file
sharing)
Caching example
origin
Assumptions
servers
average object size = 100,000 bits
public
avg. request rate from institutions Internet
browsers to origin servers =
15/sec
delay from institutional router to
1.5 Mbps
any origin server and back to access link
router = 2 sec
institutional
Consequences network
10 Mbps LAN
utilization on LAN = 15%
utilization on access link = 100%
total delay = Internet delay + access
delay + LAN delay institutional
= 2 sec + minutes + milliseconds cache
Caching example (cont.)
origin
Possible solution
servers
increase bandwidth of access link
public
to, say, 10 Mbps
Internet
Consequences
utilization on LAN = 15%
utilization on access link = 15%
10 Mbps
Total delay = Internet delay + access access link
delay + LAN delay
institutional
= 2 sec + msecs + msecs
network
often a costly upgrade 10 Mbps LAN

institutional
cache
Caching example (cont.)
origin
Install cache servers
suppose hit rate is .4 public
Consequence Internet
40% requests will be satisfied
almost immediately
60% requests satisfied by origin
server 1.5 Mbps
access link
utilization of access link reduced
to 60%, resulting in negligible institutional
delays (say 10 msec) network
10 Mbps LAN
total avg delay = Internet delay
+ access delay + LAN delay =
.6*(2.01) secs + milliseconds <
1.4 secs
institutional
cache
Conditional GET
cache server
Goal: dont send object if cache
has up-to-date cached version HTTP request msg
cache: specify date of cached If-modified-since:
<date> object
copy in HTTP request not
If-modified-since: modified
<date> HTTP response
HTTP/1.0
server: response contains no 304 Not Modified
object if cached copy is up-to-
date:
HTTP request msg
HTTP/1.0 304 Not If-modified-since:
Modified <date> object
modified
HTTP response
HTTP/1.0 200 OK
<data>
P2P file sharing
P2P file sharing
Example
Alice runs P2P client
application on her
notebook computer
Intermittently connects to
Internet; gets new IP
address for each
connection
Asks for Hey Jude All peers are servers = highly
Application displays other
peers that have copy of
Hey Jude.
Alice chooses one of the peers,
Bob.
File is copied from Bobs PC to
Alices notebook: HTTP
While Alice downloads, other
users downloads/uploads
to/from Alice.
Alices peer is both a Web client
and a transient Web server.
scalable!
P2P: centralized directory
Bob
original Napster design centralized
directory server
1) when peer connects, it 1
informs central server: peers

IP address 1

content
1 3
2) Alice queries for Hey
2 1
Jude
3) Alice requests file from Bob

Alice
P2P: problems with centralized directory

Single point of failure file transfer is

Performance bottleneck decentralized, but
Copyright infringement locating content is highly
centralized
Overlay Networks

Network on top of another network

Overlay
edge
Query flooding: Gnutella

fully distributed overlay network: graph

no central server edge between peer X and
public domain protocol Y if theres a TCP
many Gnutella clients connection
implementing protocol all active peers and edges
is overlay net
Edge is not a physical link
Given peer will typically
be connected with < 10
overlay neighbors
Gnutella: protocol
File transfer:
Query message HTTP
sent over existing
TCP connections
Query
peers forward
QueryHit
Query message
QueryHit
sent over
reverse
path Query
QueryHit

Scalability:
limited scope
flooding
Gnutella: Peer joining

1. Joining peer X must find some other peer in Gnutella

network: use list of candidate peers
2. X sequentially attempts to make TCP with peers on list
until connection setup with Y
3. X sends Ping message to Y; Y forwards Ping message.
4. All peers receiving Ping message respond with Pong
message
5. X receives many Pong messages. It can then setup
additional TCP connections
Exploiting heterogeneity: KaZaA

Each peer is either a

group leader or assigned
to a group leader.
TCP connection between
peer and its group leader.
TCP connections between
some pairs of group
leaders.
Group leader tracks the ordinary peer

content in all its group-leader peer

children. neighoring relationships

in overlay network
KaZaA: Querying

Each file has a hash and a descriptor

Client sends keyword query to its group leader
Group leader responds with matches:
For each match: metadata, hash, IP address
If group leader forwards query to other group
leaders, they respond with matches
Client then selects files for downloading
HTTP requests using hash as identifier, sent to peers
holding desired file
Socket programming
with TCP
Socket programming
Goal: learn how to build client/server application that
communicate using sockets

Socket API socket

introduced in BSD4.1 UNIX,
1981
explicitly created, used, released an OS-controlled interface
by apps (a door) into which application
process can both send and receive
client/server paradigm
messages to/from another
two types of transport service application process
via socket API:
unreliable datagram
reliable, byte stream-
oriented
Socket-programming using TCP

Socket: a door between application process and end-end-

transport protocol (UDP or TCP)
TCP service: reliable transfer of bytes from one process to
another

controlled by
controlled by process application
application process
developer
developer socket socket
TCP with TCP with controlled by
controlled by
buffers, operating
operating buffers, internet system
system variables variables

host or host or
server server
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
application viewpoint
TCP provides reliable, in-order
transfer of bytes (pipe)
between client and server
Stream jargon

A stream is a sequence of characters that

flow into or out of a process.
An input stream is attached to some input
source for the process, eg, keyboard or
socket.
An output stream is attached to an output
source, eg, monitor or socket.
Socket programming with TCP
keyboard monitor
Example client-server app:
1) client reads line from standard

inFromUser
input (inFromUser stream) , input
stream
sends to server via socket Client
(outToServer stream) Process
process
2) server reads line from socket
3) server converts line to uppercase,
sends back to client

inFromServer
outToServer
4) client reads, prints modified line output input
from socket (inFromServer stream stream

stream)
client TCP
clientSocket
socket TCP
socket

to network from network

Client/server socket interaction: TCP

Server (running on hostid) Client

create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()

TCP create socket,

wait for incoming
connection request connection setup connect to hostid, port=x
connectionSocket = clientSocket =
welcomeSocket.accept() Socket()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
Socket programming with UDP

UDP: no connection between

client and server
no handshaking
sender explicitly attaches IP application viewpoint
address and port of destination
to each packet UDP provides unreliable transfer
of groups of bytes (datagrams)
server must extract IP address,
between client and server
port of sender from received
packet
UDP: transmitted data may be
received out of order, or lost
Client/server socket interaction: UDP

Server (running on hostid) Client

create socket,
create socket,
port=x, for clientSocket =
incoming request: DatagramSocket()
serverSocket =
DatagramSocket()
Create, address (hostid, port=x,
send datagram request
read request from using clientSocket
serverSocket

write reply to
serverSocket
specifying client read reply from
host address, clientSocket
port number close
clientSocket
Summary
Our study of network apps now complete!
Application architectures specific protocols:
client-server HTTP
P2P FTP
hybrid SMTP, POP, IMAP
application service DNS
requirements: socket programming
reliability, bandwidth, delay
Internet transport service
model
connection-oriented, reliable:
TCP
unreliable, datagrams: UDP
Summary
Most importantly: learned about protocols

typical request/reply
message exchange: centralized vs.
client requests info or decentralized
service stateless vs. stateful
server responds with data, reliable vs. unreliable
status code msg transfer
message formats:
headers: fields giving info
about data
data: info being
communicated