Lecture 04

Download as pdf or txt
Download as pdf or txt
You are on page 1of 71

Cloud Computing

Professor Mangal Sain


Lecture 4

Distributed Networking
Lecture 4– Part 1

Application Layer
FTP: THE FILE TRANSFER PROTOCOL

FTP file transfer


FTP FTP
user client server
interface
user
at host remote file
local file system
system

 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: SEPARATE CONTROL, DATA CONNECTIONS
TCP control connection
 FTP client contacts FTP server port 21
at port 21, TCP is transport
protocol
TCP data connection
 client authorized over control FTP port 20 FTP
connection client server
 client browses remote directory
by sending commands over  server opens another TCP dat
control connection. a connection to transfer anot
 when server receives file her file.
transfer command, server opens  control connection: “out of ba
2nd TCP connection (for file) to nd”
client  FTP server maintains “state”:
 after transferring one file, server current directory, earlier aut
closes data connection. hentication
FTP COMMANDS, RESPONSES
Sample commands: Sample return codes
 sent as ASCII text over control  status code and phrase (as in HTTP)
channel  331 Username OK, password
 USER username required
 PASS password  125 data connection already
open; transfer starting
 LIST return list of file in current
directory  425 Can’t open data
connection
 RETR filename retrieves (gets) file
 452 Error writing file
 STOR filename stores (puts) file
onto remote host
ELECTRONIC MAIL outgoing
message queue
Three major components: user mailbox
 user agents user
agent
 mail servers mail
user
 simple mail transfer protocol: server
agent
SMTP
SMTP mail
User Agent server user

 a.k.a. “mail reader”


SMTP agent

 composing, editing, reading SMTP


mail messages mail user
server agent
 e.g., Eudora, Outlook, elm,
Mozilla Thunderbird user
 outgoing, incoming messages agent
stored on server user
agent
ELECTRONIC MAIL: MAIL SERVERS
user
Mail Servers agent
 mailbox contains incoming mail
user
messages for user server
agent
 message queue of outgoing SMTP mail
(to be sent) mail messages server user
 SMTP protocol between SMTP agent

mail servers to send email


SMTP
messages mail user
server agent
 client: sending mail
server user
 “server”: receiving mail agent
server user
agent
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


SCENARIO: ALICE SENDS MESSAGE TO BOB
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message and “to” message over the TCP
bob@someschool.edu connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message message in Bob’s mailbox
placed in message queue 6) Bob invokes his user agent
3) Client side of SMTP opens to read message
TCP connection with Bob’s
mail server

1 mail
mail
server user
user server
2 agent
agent 3 6
4 5
SAMPLE SMTP INTERACTION
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
SMTP: FINAL WORDS
 SMTP uses persistent connections Comparison with HTTP:
 SMTP requires message (header &
 HTTP: pull
body) to be in 7-bit ASCII
 SMTP: push
 SMTP server uses CRLF.CRLF to
determine end of message  both have ASCII command/response
interaction, status codes

 HTTP: each object encapsulated in


its own response msg
 SMTP: multiple objects sent in
multipart msg
MAIL MESSAGE FORMAT
SMTP: protocol for exchanging email
msgs header
blank
RFC 822: standard for text message line
format:
 header lines, e.g.,
 To: body
 From:
 Subject:
different from SMTP commands!
 body
 the “message”, ASCII characters only
MESSAGE FORMAT: MULTIMEDIA EXTENSIONS
 MIME: multimedia mail extension, RFC 2045, 2056
 additional lines in msg header declare MIME content type

From: alice@crepes.fr
MIME version To: bob@hamburger.edu
Subject: Picture of yummy crepe.
method used MIME-Version: 1.0
to encode data Content-Transfer-Encoding: base64
Content-Type: image/jpeg
multimedia data
type, subtype, base64 encoded data .....
parameter declaration .........................
......base64 encoded data
encoded data
MAIL ACCESS PROTOCOLS

SMTP SMTP access user


user
agent protocol agent

sender’s mail receiver’s mail


server server

 SMTP: delivery/storage to receiver’s 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: gmail, Hotmail, Yahoo! Mail, etc.


POP3 PROTOCOL S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
 client commands: S: +OK user successfully logged on
 user: declare username
C: list
 pass: password
S: 1 498
 server responses S: 2 912
 +OK S: .
 -ERR C: retr 1
S: <message 1 contents>
transaction phase, client: S: .
 list: list message numbers C: dele 1
 retr: retrieve message by C: retr 2
number S: <message 1 contents>
S: .
 dele: delete
C: dele 2
 quit C: quit
S: +OK POP3 server signing off
POP3 (MORE) AND IMAP
More about POP3
IMAP
 Previous example uses
 Keep all messages in one
“download and delete”
place: the server
mode.
 Allows user to organize
 Bob cannot re-read e-mail if
messages in folders
he changes client
 IMAP keeps user state
 “Download-and-keep”:
across sessions:
copies of messages on
 names of folders and
different clients mappings between message
 POP3 is stateless across IDs and folder name
sessions
DNS: DOMAIN NAME SYSTEM
People: many identifiers: Domain Name System:
 SSN, name, passport #  distributed database
Internet hosts, routers: implemented in hierarchy of
many name servers
 IP address (32 bit) - used for
addressing datagrams  application-layer protocol host,
routers, name servers to
 “name”, e.g., ww.yahoo.com
communicate to resolve names
- used by humans
(address/name translation)
Q: map between IP  note: core Internet function,
addresses and name ? implemented as application-
layer protocol
 complexity at network’s
“edge”
DNS
DNS services Why not centralize DNS?
 hostname to IP address  single point of failure
translation  traffic volume
 host aliasing
 distant centralized
 Canonical, alias names
database
 mail server aliasing  maintenance
 load distribution
 replicated Web servers:
set of IP addresses for doesn’t scale!
one canonical name
DISTRIBUTED, HIERARCHICAL DATABASE
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu


yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com:


 client queries a root server to find com DNS server

 client queries com DNS server to get amazon.com


DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com
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
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)

13 root name serv


ers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
TLD AND AUTHORITATIVE SERVERS

 Top-level domain (TLD) servers:


 responsible for com, org, net, edu, etc, and all top-level
country domains uk, fr, ca, jp.
 Network Solutions maintains servers for com TLD
 Educause for edu TLD
 Authoritative DNS servers:
 organization’s DNS servers, providing authoritative
hostname to IP mappings for organization’s servers (e.g.,
Web, mail).
 can be maintained by organization or service provider
LOCAL NAME SERVER

 does not strictly belong to hierarchy


 each ISP (residential ISP, company, university) has one.
 also called “default name server”
 when host makes DNS query, query is sent to its local DNS server
 acts as proxy, forwards query into hierarchy
P2P FILE SHARING
Example  Alice chooses one of the
 Alice runs P2P client peers, Bob.
application on her notebook  file is copied from Bob’s
computer PC to Alice’s notebook:
HTTP
 intermittently connects to
 while Alice downloads,
Internet; gets new IP address
other users uploading
for each connection
from Alice.
 asks for “Hey Jude”
 Alice’s peer is both a
 application displays other Web client and a
peers that have copy of Hey transient Web server.
Jude. All peers are servers =
highly scalable!
P2P CASE STUDY: BITTORRENT
 P2P file distribution
tracker: tracks peers torrent: group of
participating in torrent peers exchanging
chunks of a file

obtain list
of peers
trading
chunks

peer
BITTORRENT (1)

 file divided into 256KB chunks.


 peer joining torrent:
 has no chunks, but will accumulate them over
time
 registers with tracker to get list of peers, connects
to subset of peers (“neighbors”)
 while downloading, peer uploads chunks to
other peers.
 peers may come and go

 once peer has entire file, it may (selfishly)


leave or (altruistically) remain
BITTORRENT (2)

Pulling Chunks Sending Chunks: tit-for-tat


 at any given time, different  Alice sends chunks to four
peers have different subsets neighbors currently sending
of file chunks her chunks at the highest
rate
 periodically, a peer (Alice)
 re-evaluate top 4 every
asks each neighbor for list of
10 secs
chunks that they have.
 every 30 secs: randomly
 Alice issues requests for her
select another peer, starts
missing chunks sending chunks
 rarest first  newly chosen peer may
join top 4
Lecture 4– Part 2

Transport Layer
TRANSPORT VS. NETWORK LAYER
 network layer: logical communication
between hosts
 transport layer: logical communication
between processes
 relies on, enhances, network layer services
MULTIPLEXING/DEMULTIPLEXING

Demultiplexing at rcv host: Multiplexing at send host:


gathering data from multiple
delivering received segments
sockets, enveloping data with
to correct socket
header (later used for
demultiplexing)
= socket = process

P1 P4 application
application P3 P1 application P2

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
INTERNET TRANSPORT-LAYER PROTOCOLS
reliable, in-order delivery
application
 transport
network
(TCP) data link
physical
network
 congestion control data link
physical
network
data link
 flow control physical

 connection setup
unreliable, unordered
network
 data link
physicalnetwork
delivery: UDP data link
physical
 no-frills extension of “best- network
data link
application
effort” IP physical network transport
data link network

 services not available: physical data link


physical

 delay guarantees
 bandwidth guarantees
TCP VS. UDP
TCP VS. UDP
Features TCP (Yes/No) UDP (Yes/No)
(1) Ordered packets
(2) Connectionless
(3) Reliable data delivery
(no packet loss)
(4) Flow control
(5) Congestion control
(6) delay guarantees
(7) bandwidth
guarantees
TCP VS. UDP
Features TCP (Yes/No) UDP (Yes/No)
(1) Ordered packets Y N
(2) Connectionless N Y
(3) Reliable data delivery Y N
(no packet loss)
(4) Flow control Y N
(5) Congestion control Y N
(6) delay guarantees N N
(7) bandwidth N N
guarantees
UDP: USER DATAGRAM PROTOCOL [RFC 768]
 “no frills,” “bare bones”
Internet transport protocol Why is there a UDP?
 “best effort” service, UDP  no connection establishment
segments may be: (which can add delay)
 lost
 simple: no connection state
 delivered out of order to at sender, receiver
app  small segment header
 connectionless:  no congestion control: UDP
 no handshaking between can blast away as fast as
UDP sender, receiver desired
 each UDP segment
handled independently of
others
UDP: MORE
 often used for streaming
32 bits
multimedia apps
 loss tolerant Length, in source port # dest port #
 rate sensitive bytes of UDP length checksum
segment,
 other UDP uses including
 DNS header
 SNMP
 reliable transfer over UDP: Application
add reliability at application data
layer (message)
 application-specific error
recovery!
UDP segment format
PRINCIPLES OF RELIABLE DATA TRANSFER
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of


reliable data transfer protocol (rdt)
PRINCIPLES OF RELIABLE DATA TRANSFER
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of


reliable data transfer protocol (rdt)
PRINCIPLES OF RELIABLE DATA TRANSFER
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity


of reliable data transfer protocol (rdt)
RDT3.0 EXAMPLE
RDT3.0 EXAMPLE
PIPELINED PROTOCOLS
Pipelining: sender allows multiple, “in-flight”, yet-
to-be-acknowledged pkts
 range of sequence numbers must be increased
 buffering at sender and/or receiver

 Two generic forms of pipelined protocols: go-Back-N,


selective repeat
PIPELINING PROTOCOLS
Go-back-N: overview Selective Repeat: overview
 sender: up to N unACKed pkts  sender: up to N unACKed
in pipeline packets in pipeline
 receiver: only sends cumulative  receiver: ACKs individual
ACKs pkts
 doesn’t ACK pkt if there’s a gap  sender: maintains timer for
 sender: has timer for oldest each unACKed pkt
unACKed pkt  if timer expires: retransmit
 if timer expires: retransmit all only unACKed packet
unACKed packets
GO-BACK-N

Sender:
 k-bit seq # in pkt header
 “window” of up to N, consecutive unACKed pkts allowed

 ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”


may receive duplicate ACKs (see receiver)

 timer for each in-flight pkt
 timeout(n): retransmit pkt n and all higher seq # pkts in window
SELECTIVE REPEAT
 receiver individually acknowledges all correctly
received pkts
 buffers pkts, as needed, for eventual in-order delivery to
upper layer
 sender only resends pkts for which ACK not
received
 sender timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 again limits seq #s of sent, unACKed pkts
SELECTIVE REPEAT: SENDER, RECEIVER
WINDOWS
SELECTIVE REPEAT IN ACTION
TCP: OVERVIEW RFCS: 793, 1122, 1323, 2018, 2581

 point-to-point:  full duplex data:

 reliable, in-order byte  connection-oriented:


steam:
 flow controlled:
 pipelined:

 send & receive buffers


application application
writes data reads data
socket socket
door door
TCP TCP
send buffer receive buffer
segment
TCP SEQ. #’S AND ACKS

Seq. #’s: Host B


Host A
 byte stream
“number” of first User
types
byte in segment’s ‘C’
data host ACKs
receipt of
ACKs: ‘C’, echoes
 seq # of next byte back ‘C’
expected from other
side host ACKs
 cumulative ACK receipt
of echoed
‘C’

time
simple telnet scenario
TCP RELIABLE DATA TRANSFER
 TCP creates rdt service on top  retransmissions are
of IP’s unreliable service triggered by:
 pipelined segments  timeout events
 duplicate ACKs
 cumulative ACKs

 TCP uses single


retransmission timer
TCP FLOW CONTROL
flow control
sender won’t overflow
 receive side of TCP receiver’s buffer by
connection has a receive transmitting too much,
buffer: too fast

IP
(currently)
TCP data application  speed-matching service:
unused buffer
datagrams space (in buffer) process matching send rate to
receiving application’s
drain rate
 app process may be
slow at reading from
buffer
Lecture 4– Part 3

Network Layer
TWO KEY NETWORK-LAYER FUNCTIONS
 forwarding: move packets analogy:
from router’s input to
appropriate router output  routing: process of

 routing: determine route


planning trip from
taken by packets from source to dest
source to dest.
 forwarding: process
 routing algorithms of getting through
single interchange
Interplay between routing and forwarding

routing algorithm

local forwarding table


header value output link
0100 3
0101 2
0111 2
1001 1

value in arriving
packet’s header
0111 1

3 2
NETWORK LAYER CONNECTION AND CONNECTION-
LESS SERVICE

 datagram network provides network-layer connectionless


service
 VC network provides network-layer connection service
VIRTUAL CIRCUITS
“source-to-dest path behaves much like telephone
circuit”
 performance-wise
 network actions along source-to-dest path

 each packet carries VC identifier (not destination host


address)
 every router on source-dest path maintains “state” for each
passing connection
 link, router resources (bandwidth, buffers) may be allocated
to VC (dedicated resources = predictable service)
VC number
FORWARDING TABLE
12 22 32

1 3
2

Forwarding table in interface


number
northwest router:
Incoming interface Incoming VC # Outgoing interface Outgoing VC #

1 12 3 22
2 63 1 18
3 7 2 17
1 97 3 87
… … … …

Routers maintain connection state information!


VIRTUAL CIRCUITS: SIGNALING PROTOCOLS

 used in ATM, frame-relay, X.25


 not used in today’s Internet

application
6. Receive data application
transport 5. Data flow begins
network 4. Call connected 3. Accept call transport
data link 1. Initiate call 2. incoming call network
data link
physical
physical
DATAGRAM NETWORKS
 no call setup at network layer
 routers: no state about end-to-end connections
 no network-level concept of “connection”
 packets forwarded using destination host address
 packets between same source-dest pair may take different
paths

application
application
transport
transport
network
data link 1. Send data 2. Receive data network
data link
physical
physical
ROUTER ARCHITECTURE OVERVIEW
Two key router functions:
 run routing algorithms/protocol (RIP, OSPF, BGP)
 forwarding datagrams from incoming to outgoing link
THE INTERNET NETWORK LAYER
Host, router network layer functions:

Transport layer: TCP, UDP

Routing protocols IP protocol


•path selection •addressing conventions
•RIP, OSPF, BGP •datagram format
Network •packet handling conventions
layer forwarding
ICMP protocol
table
•error reporting
•router “signaling”

Link layer

physical layer
IP DATAGRAM FORMAT
IP protocol version 32 bits
number total datagram
header length type of length (bytes)
ver head. length
(bytes) len service for
“type” of data fragment fragmentation/
16-bit identifier flgs
offset reassembly
max number time to upper header
remaining hops live layer checksum
(decremented at
32 bit source IP address
each router)
32 bit destination IP address
upper layer protocol
to deliver payload to Options (if any)
data
(variable length,
typically a TCP
or UDP segment)
IP FRAGMENTATION & REASSEMBLY
 network links have MTU
(max.transfer size)
 largest possible link-level fragmentation:
frame. in: one large datagram
out: 3 smaller datagrams
 large IP datagram divided
(“fragmented”) within net
 one datagram becomes
reassembly
several datagrams
 “reassembled” only at final
destination
 IP header bits used to
identify, order related
fragments
IP ADDRESSING: INTRODUCTION

 IP address: 32-bit 223.1.1.1

identifier for host, 223.1.2.1


223.1.1.2
router interface 223.1.1.4 223.1.2.9
 interface: connection
223.1.2.2
between host/router 223.1.1.3 223.1.3.27

and physical link


 router’s typically have
multiple interfaces 223.1.3.1 223.1.3.2
 host typically has one
interface
 IP addresses associated 223.1.1.1 = 11011111 00000001 00000001 00000001
with each interface
223 1 1 1
SUBNETS

 IP address: 223.1.1.1

 subnet part (high order 223.1.1.2


223.1.2.1
bits) 223.1.1.4 223.1.2.9
 host part (low order
bits) 223.1.1.3
223.1.2.2
223.1.3.27
 What’s a subnet ?
subnet
 device interfaces with
same subnet part of IP 223.1.3.1 223.1.3.2
address
 can physically reach
each other without
intervening router network consisting of 3 subnets
DHCP: DYNAMIC HOST CONFIGURATION PROTOCOL

Goal: allow host to dynamically obtain its IP address from


network server when it joins network
 Allows reuse of addresses

A 223.1.1.1 DHCP 223.1.2.1


server
223.1.1.2
223.1.1.4 223.1.2.9
B
223.1.2.2 arriving DHCP
223.1.1.3 223.1.3.27 E client needs
address in this
223.1.3.1 223.1.3.2
network
NAT: NETWORK ADDRESS TRANSLATION
rest of local network
Internet (e.g., home network)
10.0.0/24 10.0.0.1

10.0.0.4
10.0.0.2
138.76.29.7

10.0.0.3

All datagrams leaving local Datagrams with source or


network have same single source NA destination in this network
T IP address: 138.76.29.7, have 10.0.0/24 address for
different source port numbers source, destination (as usual)
NAT: NETWORK ADDRESS TRANSLATION
 Motivation:local network uses just one IP
address as far as outside world is concerned:
 range of addresses not needed from ISP: just one IP
address for all devices
 can change addresses of devices in local network
without notifying outside world
 can change ISP without changing addresses of devices
in local network
 devices inside local net not explicitly addressable,
visible by outside world (a security plus).
IPV6

 Initial motivation: 32-bit address space soon to be


completely allocated.
 Additional motivation:
 header format helps speed processing/forwarding
 header changes to facilitate QoS
IPv6 datagram format:
 fixed-length 40 byte header
 no fragmentation allowed
IPV6 HEADER (CONT)

Priority: identify priority among datagrams in flow


Flow Label: identify datagrams in same “flow.”
(concept of“flow” not well defined).
Next header: identify upper layer protocol for data

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy