1. Sockets, part 2 (Addresses, poll())
Eric Freudenthal

2. Problem: adding network to programming model
What’s needed? Way to:
Represent stream connections (read, write)
Like files, are just an ordered sequence of bytes
Lots of libraries & programmers already know files
Try to emulate files as much as possible
Represent stream listeners (accept)
Accept connections
Factory for stream connections
Portals for datagrams (sendto, recvfrom)
Permit sending and receiving of datagrams
Same for many stream and datagram protocols
Make as universal as possible

3. Specifying addresses Servers need to specify addresses
So clients can contact them
Clients may not need this (unless p2p)
Hosts may have multiple addresses
Multiple interfaces
If appropriate, socket should be able to communicate to only one, or many
Protocol may implement “ports” at an address
Big idea: “universal” address specifier
Contains protocol, address,
(and if appropriate) port identifier

4. Making addresses generic
Low level
Easy in OO languages
Messy in C
Define multiple struct types
With identical prolog containing discriminator word
Reference using pointers, let socket figure things out
Higher level: using strings or cs.utep.edu
Nicely human readable
Nuisance methods convert strings to generic addr struct
Described in detail within Donohoo book

5. Stream socket operations
Stream listener (server) sockets:
Bind(fd, ...) to address
Accept(fd, …) client connections (returns stream)
Connected stream socket knows address of client
Stream client sockets
Optional: bind(fd, …) to address
Connect(fd, …) to listener (specify server address)
Once connected: connected stream support
Read(fd, …) & write(fd, …) data; close(fd) connection
Can receive enqueued data if other end already closed
Request addr of other end

6. Datagram socket operations
Bind(fd, …) to address
May only be done for server
Sendto(fd, buffer, address)
Recvfrom(fd, buffer, address)
Close(fd)

7. Dealing with asynchrony
Problem: waiting for data
That may arrive from multiple sockets
that may not arrive (in time)
Classic (inefficient and messy) approach
Use threads:
One thread waits for data on each input socket
Other threads worry about data not arriving “in time”
Getting the interactions right is messy and error-prone
Rarely is any benefit derived from apparent parallelism
Modern approach: select(), poll(), and epoll()
Non-blocking socket requests
Operations never block – either work or fail immediately
OS told all requirements
Program tells OS which socket states matter & timeout
Lets program know when socket is ready or if timeout occurred first
We will examine & use poll

8. Big idea 1: classify socket events
Types of socket events
Rec’d data available for reading (POLLIN)
Also accept for listener sockets
Ready to accept data for sending (POLLOUT)
Note datagram sockets always ready for this!
No more data will be rec’d (POLLRDHUP)
Closed (POLLHUP)
Error (POLLERR)
Invalid request (e.g. fd closed: POLLNVAL)
More, but esotheric for us, see: man 2 poll
Each specified by a different bit

9. Big idea 2: pollfd vector
Role: represent sockets & needed events
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events */
short revents; /* returned events */ };
Struct
#define FdLimit 32 // hack
struct pollfd pollvec[FdLimit];

10. Selecting next action based upon poll system call
int poll(struct pollfd *pollFds, nfds_t nfds, int timeout);
Parameters:
pollFds: vector of pollfds (each contains fd, request, return)
Nfds: # of entries in pollfds[] (length of array)
Timeout: in milliseconds
Upon return
Return entries in pollFds are set
Return value = #events satisfied
Zero for timeout
Or negative on failure (see errno)

11. Lab 2 Create a reliable file-transfer system using udp Server: Client:
awaits and responds to requests
Obtains file from filesystem
Sends data reliably to client
Client:
User specifies requested filename & name to store
File obtained using UDP and stored in filesystem
Ideally
protocol and implementation robust to message loss
You should hand in a tarfile containing only:
Source files, Makefile, and readme.txt

12. Rest of the slides are on epoll
Epoll is not so widely available, but is likely to eventually replace poll.
Feel free to use epoll if your system supports it.

13. Big idea 1: classify socket events
Types of socket events
Rec’d data available for reading (EPOLLIN)
Ready to accept data for sending (EPOLLOUT)
Note datagram sockets always ready for this!
No more data will be rec’d (EPOLLRDHUP)
Closed (EPOLLHUP)
Error (EPOLLERR)
More, but esotheric for us, see: man 2 epoll_ctl
Each specified by a different bit

14. Big idea 2: event descriptor
Role: register sockets & needed events
Epoll_create(size): see man 2 epoll_create
Size: hint indicating how many sockets to manage
Returns: epfd, which serves as an event descriptor
Epoll_set(epfd, op, fd, epoll_event)
Epfd: epoll event descripter
Fd: fd of interest
Op: EPOLL_CTL_ADD, _MOD, or _DEL
Event: from previous slide, and extra integer
See: man 2 epoll_create

15. Details of an epoll_event
typedef union epoll_data { // optional void *ptr; int fd; uint32_t u32; uint64_t u64; }epoll_data_t; struct epoll_event { uint32_t events; // Epoll events epoll_data_t data; // User data var }

16. Selecting next action using epoll
Epoll_wait(epfd, eventReportArray, timeout)
Epfd: already configured epoll event descriptor
eventReportArray: two parameters
Pointer to array of empty epoll events
Length of this array (maximum # of events reported)
Will be filled in with reported events
Timeout: in milliseconds
Returns:
# of reported events (0 on timeout)
Program should check the report array
Negative value if error
See: man 2 epoll_wait