1. CS 5565 Network Architecture and Protocols
Lecture 5
Godmar Back

2. Announcements Problem Set 1 due Feb 18 Project 1A due Feb 19
CS 5565 Spring 2009
12/31/2018

3. Queuing Layer k+1 send queues recv queues Layer k Layer k-1
CS 5565 Spring 2009
12/31/2018

4. Demultiplexing
End systems must decide which layer instances should process an incoming packet
Layer k has “type information” in header to say which instance of layer k+1 to pick
Issues: speed and flexibility
Ethernet Frame as received
Ethernet Type …… >IP
IP Protocol ……06 ->TCP.….
TCP Port ……50 ->http.….
Http Request ……GET /~gback.….
Ethernet Header IP Header TCP Header HTTP Request
CS 5565 Spring 2009
12/31/2018

5. Demultiplexing Issues (1)
How does a layer k determine which layer k+1 should get a packet?
Generally done using dispatch/function pointer table indexed by known/registered protocols
Works well layer to layer
But… can’t see if a packet will be accepted by (or is useful to) higher layers
CS 5565 Spring 2009
12/31/2018

6. Demultiplexing Issues (2)
Receiver Livelock:
Spending entire CPU cycles doing low-level processing on packets that eventually need to be discarded.
Goal: Early Packet Discard
(On interrupt): don’t waste time on packets that you need to discard anyway
Because no one’s listening
Or: because listener doesn’t keep up (application slow, buffers full, etc.)
Combined with Lazy Receiver Processing (LRP)
After initial acceptance, postpone further processing to accounted context
See for details
CS 5565 Spring 2009
12/31/2018

7. Demultiplexing Issues (3)
How do you achieve early packet discard?
Often: optimize common case, support a few well-known protocols
Better/more general solution:
Allow higher layers to register demultiplexing predicates, e.g.
(eth.type == IP && ip.prot == TCP && tcp.port == http && http.req matches ‘/~gback/’)
Ideally composable
Must be safe
BPF: Berkeley Packet Filter – interpreted language to decide if a packet matches or not
CS 5565 Spring 2009
12/31/2018

8. Fast Demux: DPF [Engler’96]
Uses dynamic code generation to install demux filters
CS 5565 Spring 2009
12/31/2018

9. Scout OS Developed at U Arizona by Larry Peterson
Idea: center entire OS around “network paths”
“communication OS”
data-driven scheduling
Path 1
Path2
CS 5565 Spring 2009
12/31/2018

10. Arguments against Layering
Design
Some functions don’t fit in a layer
network management
Possibility of making (and having to live with) bad design decisions
Possibility of duplication
Performance
Possible performance penalties from crossing layers: memory-to-memory copies
Mistuning: (Old) layer implementation at k+1 may be suboptimal when (new) layer k is improved
CS 5565 Spring 2009
12/31/2018

11. Layering not always strict
Example: FDDI Station Management
CS 5565 Spring 2009
12/31/2018

12. End-To-End Argument
If you were to design a network from scratch, how would you decide which functionality goes in which layer?
E2E Argument [Saltzer/Reed/Clark ’84] says:
Functionality whose complete & correct implementation requires knowledge that only end points have should be implemented at the end points.
Corollary: only put in layer ‘k’ that which benefits all instances of layer ‘k+1’
Example: file transfer
Where should you put error recovery?
NB: be careful to define end points
Human phone conversation vs. speech message system
Guiding principle, not hard rule
CS 5565 Spring 2009
12/31/2018

13. Architecture vs. Engineering
Clark & Tennenhouse [SIGCOMM 1990]
Architectural Considerations for a New Generation of Protocols
Layering but one design/engineering principle: not always best
Argue for “flexible decomposition”
Suggest two alternate ideas
Application-level Framing (ALF)
Integrated Layer Processing (ILP)
CS 5565 Spring 2009
12/31/2018

14. The Application Layer

15. Application Layer
Let’s look at some applications (in keeping with top-down)
Application architectures:
Client/Server, P2P, Hybrid
Client/Server Architecture vs Client Process/Server Process
Transport Layer Requirements
CS 5565 Spring 2009
12/31/2018

16. Creating a network app Write programs that
run on different end systems and communicate over a network.
No software typically written for devices in network core
Network core devices do not function at app layer
This design allows for rapid app development
Exception: extensible routers
Research: active networks
application
transport
network
data link
physical
CS 5565 Spring 2009
12/31/2018

17. Client-Server Architecture
always-on host
permanent IP address
server farms for scaling
clients:
communicate with server
may be intermittently connected
may have dynamic IP addresses
do not communicate directly with each other
CS 5565 Spring 2009
12/31/2018

18. Pure P2P Architecture no always on server
arbitrary end systems directly communicate
peers are intermittently connected and change IP addresses
example: Gnutella
Highly scalable
But difficult to manage
CS 5565 Spring 2009
12/31/2018

19. Hybrid of client-server and P2P
(Original) BitTorrent
File transfer P2P; Tracker centralized
Instant messaging
Presence detection/location centralized:
User registers its IP address with central server when it comes online
User contacts central server to find IP addresses of buddies
Chatting between two users can be P2P
File transfer between users typically P2P
CS 5565 Spring 2009
12/31/2018

20. App-layer Protocols Public-domain protocols: defined in RFCs
Defines:
Types of messages exchanged, e.g., request & response messages
Syntax of message types: what fields in messages & how fields are delineated
Semantics of the fields, ie, meaning of information in fields
Rules for when and how processes send & respond to messages
Public-domain protocols:
defined in RFCs
allows for interoperability
e.g., HTTP, SMTP
Proprietary protocols:
e.g., Skype
CS 5565 Spring 2009
12/31/2018

21. Transport Service Requirements
Application
file transfer
web documents
real-time audio/video
stored audio/video
interactive games
instant messaging
Data loss
no loss
loss-tolerant
Bandwidth
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
Time Sensitive no
no (?)
yes, 100’s msec
yes, few secs
yes and no
CS 5565 Spring 2009
12/31/2018

22. Internet apps: application, transport protocols
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
proprietary
(e.g. RealNetworks)
(e.g., Skype)
Underlying
transport protocol
TCP
TCP or UDP
typically UDP
Application
remote terminal access
Web
file transfer
streaming multimedia
Internet telephony
CS 5565 Spring 2009
12/31/2018

23. Communicating Processes
Client process: process that initiates communication
Server process: process that waits to be contacted
Process: program running within a host.
Access services through sockets
Note 1: client/server process is really a property of socket state
Note 2: process can be both server & client process for different communications when multiple sockets are used
CS 5565 Spring 2009
12/31/2018

24. Addressing Processes
For a process to receive messages, it must have an identifier
A host has a unique 32-bit IP address
Not sufficient because multiple processes can be on same host
Add 16-bit port number
Identifier includes both the IP address and port number associated with the process on the host.
Example port numbers:
HTTP server: 80
Mail server: 25
“Well-known” port numbers
/etc/services
CS 5565 Spring 2009
12/31/2018

25. UDP & Socket Programming

26. UDP Service provided Passes segments straight to IP
source port #
dest port #
32 bits
Application
data
(message)
UDP segment format
length
checksum
Length, in
bytes of UDP
segment,
including
header
Service provided
Demultiplexing
Payload checksum
Passes segments straight to IP
No congestion control
So simple it fits on one slide
CS 5565 Spring 2009
12/31/2018

27. Socket Programming Socket API
Goal: learn how to build client/server application that communicate using sockets
a host-local,
application-created,
OS-controlled interface (a “door”) into which
application process can both send and
receive messages to/from another application process
socket
Socket API
introduced in BSD 4.1 UNIX, 1981
explicitly created, used, released by apps
used for both local and remote communication
CS 5565 Spring 2009
12/31/2018

28. Network Socket Programming
Socket: (narrow definition:) a door between application process and end-end-transport protocol (UDP or TCP)
process
Stack w/
buffers,
variables
socket
controlled by
application
developer
operating
system
host or
server
internet
CS 5565 Spring 2009
12/31/2018

29. Addressing
For UDP/IP or TCP/IP socket communication, generally need 4 parameters:
Source Identifier (32-bit IP Address)
Source Port (16-bit)
Destination Identifier (32-bit IP Address)
Destination Port (16-bit)
Notice that the relationship of “local” and “remote” (also called “peer”) to source/destination depends on direction of communication
Note:
UDP uses only Destination (IP+Port) for demultiplexing
TCP uses Source + Destination
(quadruple: Src IP, Src Port, Dst IP, Dest Port)
CS 5565 Spring 2009
12/31/2018

30. BSD Socket API API – Application Programming Interface
Provides access to services
Specified in C language
Implemented on many platforms in one way or the other
(Windows: WinSock2, CSocket MFC classes for BSD-like look)
Sockets (in Unix) are file descriptors
General idea: writing to the socket is sending data to network, reading from socket is receiving data
Good because read(2), write(2), close(2) and others (select(2), poll(2), ioctl(2), SIGIO, fcntl(2)) can be reused
Bad because ?
Study C API first and observe how other languages embedded sockets
CS 5565 Spring 2009
12/31/2018

31. UDP Sockets: Overview Client Server socket() socket()
connect() (optional)
bind()
send()
acts like
sendto()
recvfrom()
recv()
acts like
recvfrom()
sendto()
Client Server
CS 5565 Spring 2009
12/31/2018

32. int socket(int domain, int type, int protocol)
domain: PF_INET, PF_UNIX, PF_INET6, ….
type: SOCK_DGRAM, SOCK_STREAM, …
protocol:
0 for Unspecified (or IPPROTO_UDP)
returns integer file descriptor
entirely between process and OS – no network actions involved whatsoever
man pages: ip(7), udp(7), tcp(7), socket(2), socket (7), unix(7)
type “man 2 socket”, “man 7 socket”
CS 5565 Spring 2009
12/31/2018

33. int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen)
sockfd: return by socket()
my_addr: “socket address”
addrlen
length of address (address is variable-sized data structure)
“binds” socket to (local) address specified
This affects network protocol namespace, but no information is transmitted over network
Typically: one socket per port, exception: multicast
CS 5565 Spring 2009
12/31/2018

34. How are addresses represented?
struct sockaddr { /* GENERIC TYPE, should be “abstract” */
sa_family_t sa_family; /* address family */
char sa_data[14]; /* address data */ };
/* This is the concrete “subtype” you’ll use */
struct sockaddr_in {
sa_family_t sin_family; /* address family: AF_INET */
u_int16_t sin_port; /* port in network byte order */
struct in_addr sin_addr; /* internet address */
/* Internet address. */
struct in_addr {
u_int32_t s_addr; /* address in network byte order */
CS 5565 Spring 2009
12/31/2018

35. More on bind(2) Address specified is the “local” address
Which is destination for receive and source for sends.
sin_addr.s_addr useful for “multi-homed” hosts, otherwise use INADDR_ANY
sin_port may be zero if any port would do
Use getsockname() to retrieve assigned port
s_addr and sin_port are specified in network byte order
This convention holds throughout socket API
CS 5565 Spring 2009
12/31/2018

36. Common Pitfalls (1) Network vs. Host Byte order
Network order is big endian, most-significant byte first
Host order may be either big or little: little endian on x86
Use ntohs(), ntohl(), htons(), htonl() to convert 16-bit (“short”) and 32-bit (“long”) values portably
Never convert addresses/ports in sockaddr_in structures in place
Not as much an issue in languages that hide data representation (e.g., Java)
CS 5565 Spring 2009
12/31/2018

37. int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
Common Pitfalls (2)
Pay attention to “length” parameters
Example
namelen here is not OUT, its INOUT
aka value-result
You know what socket it is, the OS doesn’t!
Always check return codes!
int getsockname(int s, struct sockaddr *name, socklen_t *namelen);
CS 5565 Spring 2009
12/31/2018

38. sendto(2), recvfrom(2) s, buf, len as in read/write
ssize_t sendto(int s, const void *buf, size_t len, int flags, const
struct sockaddr *to, socklen_t tolen);
ssize_t recvfrom(int s, void *buf, size_t len, int flags,
struct sockaddr *from, socklen_t *fromlen);
s, buf, len as in read/write
flags: MSG_OOB, MSG_PEEK – mostly 0
to/from are of type struct sockaddr_in
These are remote/peer addresses: where did the packet come from, where should it be sent to
NB: fromlen is value-result!
CS 5565 Spring 2009
12/31/2018

39. Then what does connect() do???
UDP & connect(2)
Then what does connect() do???
No notion of connections in UDP
connect(2) can be used to tell OS “default destination” for future sends
Then can use send(2) and write(2) instead of sendto(2), or can omit the destination address in sendto(2)
What does “ECONNREFUSED” mean for UDP?
Courtesy extended by other nodes which send ICMP packet saying “no one’s listening for UDP packets at the port number you sent it to”
OS relayed this information to UDP application
CS 5565 Spring 2009
12/31/2018

40. UDP Demultiplexing Payload Payload Payload
S: :3045 D: :80
Payload
S: :???
sendto( :80)
socket()
bind(*, 80)
S: :80
socket()
S: :3045
recvfrom(&from) from: :3045
recvfrom(&from) from: :512
S: :512 D: :80
Payload
recvfrom(&from) from: :512
S: :53
bind(*, 53)
S: :512
bind( ,512)
S: :512 D: :53
Payload
CS 5565 Spring 2009
12/31/2018