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

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

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

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 10.1.1.15 or cs.utep.edu Nicely human readable Nuisance methods convert strings to generic addr struct Described in detail within Donohoo book

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

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

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

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

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];

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)

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

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.

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

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

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 }

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