Carnegie Mellon
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
1
14
–
513
18
–
613

Carnegie Mellon
Network Programming: Part II
15-213/18-213/14-513/15-513/18-613: Introduction to Computer Systems
23rd Lecture, November 17, 2020
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 2

Carnegie Mellon
2. Start client Client
1. Start server Server
Review: Echo
Server
+ Client
Structure
Await connection request from client
3. Exchange data
open_clientfd
Connection request
accept
Client / Server Session
terminal read
socket write
socket read
terminal write
4. Disconnect client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
5. Drop client
close
EOF
socket read
close
open_listenfd
socket read
socket write
4

Carnegie Mellon
Today
 The Sockets Interface
 Web Servers
 The Tiny Web Server
 Serving Dynamic Content
CSAPP 11.4
CSAPP 11.5.1-11.5.3 CSAPP 11.6
CSAPP 11.5.4
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
5

Carnegie Mellon
Start client
Client
getaddrinfo
socket
Start server
Server
getaddrinfo
socket
bind listen
Sockets Interface
open_listenfd
open_clientfd
Connection request
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
6
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Review: Generic Socket Address  Generic socket address:
▪ For address arguments to connect, bind, and accept
struct sockaddr {
uint16_t sa_family; /* Protocol family */ char sa_data[14]; /* Address data. */
};
sa_family
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
7
Family Specific

Carnegie Mellon
Review: Socket Address Structures  Internet (IPv4) specific socket address:
▪ Must cast (struct sockaddr_in *) to (struct sockaddr *) for functions that take socket address arguments.
struct sockaddr_in {
uint16_t sin_family; /* Protocol family (always AF_INET) */ uint16_t sin_port; /* Port num in network byte order */ struct in_addr sin_addr; /* IP addr in network byte order */ unsigned char sin_zero[8]; /* Pad to sizeof(struct sockaddr) */
};
sa_family
sin_family
Family Specific
sin_port sin_addr
AF_INET
0
0
0
0
0
0
0
0
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
8

Carnegie Mellon
Review: getaddrinfo
 getaddrinfo converts string representations of hostnames,
host addresses, ports, service names to socket address structures
SA list
addrinfo structs
ai_canonname
result
Socket address structs
ai_addr
ai_next
NULL
ai_addr
ai_next
NULL
ai_addr
NULL
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
9

Carnegie Mellon
Start client
Client
getaddrinfo
SA list
Start server
Server
getaddrinfo
SA list
socket
bind listen
Sockets Interface
open_listenfd
socket
open_clientfd
Connection request
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
10
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Sockets Interface: socket
 Clients and servers use the socket function to create a socket descriptor:
int socket(int domain, int type, int protocol)
 Example:
int clientfd = socket(AF_INET, SOCK_STREAM, 0);
Indicates that we are using Indicates that the socket 32-bit IPV4 addresses will be the end point of a reliable (TCP) connection
Protocol specific! Best practice is to use getaddrinfo to generate the parameters automatically, so that code is protocol independent.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 11

Carnegie Mellon
Client
getaddrinfo
socket
SA list
Start server
Server
getaddrinfo
SA list
listenfd
Sockets Interface
open_listenfd
socket
clientfd
open_clientfd
bind
listen
Connection request
connect
accept
Client / Server Session
Await connection request from next client
rio_writen
rio_readlineb
rio_writen
rio_readlineb
close
EOF
rio_readlineb
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
12
close

Carnegie Mellon
Sockets Interface: bind
 A server uses bind to ask the kernel to associate the
server’s socket address with a socket descriptor:
int bind(int sockfd, SA *addr, socklen_t addrlen);
Our convention: typedef struct sockaddr SA;
 Process can read bytes that arrive on the connection whose
endpoint is addr by reading from descriptor sockfd  Similarly, writes to sockfd are transferred along
connection whose endpoint is addr
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 13

Carnegie Mellon
Client
getaddrinfo
SA list
socket
clientfd
Server
getaddrinfo
SA list
socket
listenfd
listenfd <-> SA
Sockets Interface
open_listenfd
open_clientfd
bind
Connection request
listen
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
15
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Sockets Interface: listen
 Kernel assumes that descriptor from socket function is an
active socket that will be on the client end
 A server calls the listen function to tell the kernel that a
descriptor will be used by a server rather than a client:
int listen(int sockfd, int backlog);
 Converts sockfd from an active socket to a listening socket that can accept connection requests from clients.
 backlog is a hint about the number of outstanding connection requests that the kernel should queue up before starting to refuse requests (128-ish by default)
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 16

Carnegie Mellon
Client
getaddrinfo
SA list
socket
clientfd
Server
getaddrinfo
SA list
socket
listenfd
listenfd <-> SA
Sockets Interface
open_listenfd
open_clientfd
bind
Connection request
listening listenfd
listen
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
17
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Sockets Interface: accept
 Servers wait for connection requests from clients by
calling accept:
int accept(int listenfd, SA *addr, int *addrlen);
 Waits for connection request to arrive on the connection bound to listenfd, then fills in client’s socket address in addr and size of the socket address in addrlen.
 Returns a connected descriptor connfd that can be used to communicate with the client via Unix I/O routines.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 18

Carnegie Mellon
Client
getaddrinfo
SA list
clientfd
Server
getaddrinfo
SA list
listenfd
listenfd <-> SA
Sockets Interface
open_listenfd
socket
socket
open_clientfd
bind
Connection request
listening listenfd
listen
connect
accept
Client / Server Session
Await connection request from next client
rio_writen
rio_readlineb
rio_writen
rio_readlineb
close
EOF
rio_readlineb
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
19
close

Carnegie Mellon
Sockets Interface: connect
 A client establishes a connection with a server by calling connect:
int connect(int clientfd, SA *addr, socklen_t addrlen);
 Attempts to establish a connection with server at socket address addr
▪ If successful, then clientfd is now ready for reading and writing. ▪ Resulting connection is characterized by socket pair
(x:y, addr.sin_addr:addr.sin_port)
▪ x is client address
▪ y is ephemeral port that uniquely identifies client process on client host
Best practice is to use getaddrinfo to supply the arguments addr and addrlen.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 20

Carnegie Mellon
connect/accept Illustrated listenfd
Client
clientfd
Connection request
Client
clientfd
Server
1. Server blocks in accept, waiting for connection request on listening descriptor listenfd
2. Client makes connection request by calling and blocking in connect
listenfd
Server
Client
clientfd
listenfd
Server
connfd
3. Server returns connfd from accept. Client returns from connect. Connection is now established between clientfd and connfd
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
21

Carnegie Mellon
Connected vs. Listening Descriptors
 Listening descriptor
▪ End point for client connection requests
▪ Created once and exists for lifetime of the server
 Connected descriptor
▪ End point of the connection between client and server
▪ A new descriptor is created each time the server accepts a connection request from a client
▪ Exists only as long as it takes to service client  Why the distinction?
▪ Allows for concurrent servers that can communicate over many client connections simultaneously
▪ E.g., Each time we receive a new request, we fork a child to handle the request
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 22

Carnegie Mellon
Client
getaddrinfo
SA list
socket
clientfd
Server
getaddrinfo
SA list
socket
listenfd
listenfd <-> SA
Sockets Interface
open_listenfd
open_clientfd
bind
Connection request
listening listenfd
connected connfd
Await connection request from next client
listen
connect
accept
Client / Server Session
rio_writen
connected (to SA) clientfd
rio_readlineb
rio_writen
rio_readlineb
close
EOF
rio_readlineb
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
23
close

Carnegie Mellon
Client
getaddrinfo
socket
Server
getaddrinfo
socket
bind
listen
Sockets Interface
open_listenfd
open_clientfd
Connection request
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
24
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Sockets Helper: open_clientfd  Establish a connection with a server
int open_clientfd(char *hostname, char *port) { int clientfd;
struct addrinfo hints, *listp, *p;
/* Get a list of potential server addresses */
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_socktype = SOCK_STREAM; /* Open a connection */ hints.ai_flags = AI_NUMERICSERV; /* …using numeric port arg. */ hints.ai_flags |= AI_ADDRCONFIG; /* Recommended for connections */ Getaddrinfo(hostname, port, &hints, &listp);
csapp.c
AI_ADDRCONFIG – uses your system’s address type.
You have at least one IPV4 iface? IPV4. At least one IPV6? IPV6.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 25

Carnegie Mellon
getaddrinfo
addrinfo structs
ai_canonname
Socket address structs
result
ai_addr
ai_next
NULL
ai_addr
ai_next
NULL
ai_addr
NULL
 Clients: walk this list, trying each socket address in turn, until the calls to socket and connect succeed.
 Servers: walk the list until calls to socket and bind succeed.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 26

Carnegie Mellon
Sockets Helper: open_clientfd (cont)
}
csapp.c
/* Walk the list for one that we can successfully connect to */
for (p = listp; p; p = p->ai_next) {
/* Create a socket descriptor */
if ((clientfd = socket(p->ai_family, p->ai_socktype,
p->ai_protocol)) < 0) continue; /* Socket failed, try the next */ /* Connect to the server */ if (connect(clientfd, p->ai_addr, p->ai_addrlen) != -1) break; /* Success */
Close(clientfd); /* Connect failed, try another */ }
/* Clean up */
Freeaddrinfo(listp);
if (!p) /* All connects failed */
return -1;
else /* The last connect succeeded */
return clientfd;
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 27

Carnegie Mellon
Client
getaddrinfo
socket
Server
getaddrinfo
socket
bind
listen
Sockets Interface
open_listenfd
open_clientfd
Connection request
Client / Server Session
Await connection request from next client
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
28
connect
rio_writen
rio_readlineb
close
EOF
rio_readlineb
accept
rio_readlineb
rio_writen
close

Carnegie Mellon
Sockets Helper: open_listenfd
 Create a listening descriptor that can be used to accept
connection requests from clients.
int open_listenfd(char *port)
{
struct addrinfo hints, *listp, *p; int listenfd, optval=1;
/* Get a list of potential server addresses */
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_socktype = SOCK_STREAM; /* Accept connect. */ hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; /* …on any IP addr */ hints.ai_flags |= AI_NUMERICSERV; /* …using port no. */ Getaddrinfo(NULL, port, &hints, &listp);
csapp.c
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 29

Carnegie Mellon
Sockets Helper: open_listenfd (cont)
/* Walk the list for one that we can bind to */
for (p = listp; p; p = p->ai_next) {
/* Create a socket descriptor */
if ((listenfd = socket(p->ai_family, p->ai_socktype,
p->ai_protocol)) < 0) continue; /* Socket failed, try the next */ /* Eliminates "Address already in use" error from bind */ Setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, (const void *)&optval , sizeof(int)); /* Bind the descriptor to the address */ if (bind(listenfd, p->ai_addr, p->ai_addrlen) == 0) break; /* Success */
Close(listenfd); /* Bind failed, try the next */ }
csapp.c
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 30

Carnegie Mellon
Sockets Helper: open_listenfd (cont)
/* Clean up */
Freeaddrinfo(listp);
if (!p) /* No address worked */
return -1;
/* Make it a listening socket ready to accept conn. requests */
if (listen(listenfd, LISTENQ) < 0) { Close(listenfd); return -1; } return listenfd; } csapp.c  Key point: open_clientfd and open_listenfd are both independent of any particular version of IP. Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 31 Carnegie Mellon Testing Servers Using telnet  The telnet program is invaluable for testing servers that transmit ASCII strings over Internet connections ▪ Our simple echo server ▪ Web servers ▪ Mail servers  Usage: ▪ linux> telnet ▪ Creates a connection with a server running on and listening on port Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 32

Carnegie Mellon
Testing the Echo Server With telnet
whaleshark> ./echoserveri 15213
Connected to (MAKOSHARK.ICS.CS.CMU.EDU, 50280) server received 11 bytes
server received 8 bytes
makoshark> telnet whaleshark.ics.cs.cmu.edu 15213 Trying 128.2.210.175…
Connected to whaleshark.ics.cs.cmu.edu (128.2.210.175). Escape character is ‘^]’.
Hi there!
Hi there!
Howdy!
Howdy!
^]
telnet> quit Connection closed. makoshark>
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 33

Carnegie Mellon
Today
 The Sockets Interface
 Web Servers
 The Tiny Web Server
 Serving Dynamic Content
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 34

Carnegie Mellon
Web Server Basics
 Clientsandserverscommunicate using the HyperText Transfer Protocol (HTTP)
▪ Client and server establish TCP connection
▪ Client requests content
▪ Server responds with requested
content
▪ Client and server close connection (eventually)
 Current version is HTTP/1.1 ▪ RFC 2616, June, 1999.
HTTP request Web
client (browser)
Web server
HTTP response (content)
Web content Streams Datagrams
HTTP
TCP
IP
http://www.w3.org/Protocols/rfc2616/rfc2616.html
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
35

Carnegie Mellon
Web Content
 Web servers return content to clients
▪ content: a sequence of bytes with an associated MIME (Multipurpose Internet Mail Extensions) type
 Example MIME types ▪ text/html
▪ text/plain ▪ image/gif ▪ image/png ▪ image/jpeg
HTML document
Unformatted text
Binary image encoded in GIF format Binary image encoded in PNG format Binary image encoded in JPEG format
You can find the complete list of MIME types at:
http://www.iana.org/assignments/media-types/media-types.xhtml
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 36

Carnegie Mellon
Static and Dynamic Content
 The content returned in HTTP responses can be either static or dynamic
▪ Static content: content stored in files and retrieved in response to an HTTP request
▪ Examples: HTML files, images, audio clips, Javascript programs
▪ Request identifies which content file
▪ Dynamic content: content produced on-the-fly in response to an HTTP
request
▪ Example: content produced by a program executed by the server on behalf of the client
▪ Request identifies file containing executable code
 Web content associated with a file that is managed by the server
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 37

Carnegie Mellon
URLs and how clients and servers use them
 Unique name for a file: URL (Universal Resource Locator)
 Example URL: http://www.cmu.edu:80/index.html
 Clients use prefix (http://www.cmu.edu:80) to infer:
▪ What kind (protocol) of server to contact (HTTP) ▪ Where the server is (www.cmu.edu)
▪ What port it is listening on (80)
 Servers use suffix (/index.html) to:
▪ Determine if request is for static or dynamic content.
▪ No hard and fast rules for this
▪ One convention: executables reside in cgi-bin directory
▪ Find file on file system
▪ Initial “/” in suffix denotes home directory for requested content.
▪ Minimal suffix is “/”, which server expands to configured default filename (usually, index.html)
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 38

Carnegie Mellon
HTTP Requests
 HTTP request is a request line, followed by zero or more
request headers
 Request line:
▪ is one of GET, POST, OPTIONS, HEAD, PUT,
DELETE, or TRACE
▪ is typically URL for proxies, URL suffix for servers
▪ A URL is a type of URI (Uniform Resource Identifier)
▪ See http://www.ietf.org/rfc/rfc2396.txt
▪ is HTTP version of request (HTTP/1.0 or HTTP/1.1)
 Request headers: