Lecture 4: Networked Applications & Sockets Reading: Chapter 1 ? CMSC 23300/33300 Computer Networks

2 Goals of Today’s Lecture l Client-server paradigm u End systems u Clients and servers l Sockets u Socket abstraction u Socket programming in UNIX

3 End System: Computer on the Net Internet Also known as a “host”…

4 Clients and Servers l Client program u Running on end host u Requests service u E.g., Web browser l Server program u Running on end host u Provides service u E.g., Web server GET /index.html “Site under construction”

5 Clients Are Not Necessarily Human l Example: Web crawler (or spider) u Automated client program u Tries to discover & download many Web pages u Forms the basis of search engines like Google l Spider client u Start with a base list of popular Web sites u Download the Web pages u Parse the HTML files to extract hypertext links u Download these Web pages, too u And repeat, and repeat, and repeat…

6 Client-Server Communication l Client “sometimes on” u Initiates a request to the server when interested u E.g., Web browser on your laptop or cell phone u Doesn’t communicate directly with other clients u Needs to know the server’s address l Server “always on” u Services requests from many client hosts u E.g., Web server for the Web site u Doesn’t initiate contact with the clients u Needs a fixed, well- known address

7 Peer-to-Peer Communication l No always-on server at the center of it all u Hosts can come and go, and change addresses u Hosts may have a different address each time l Example: peer-to-peer file sharing u Any host can request files, send files, query to find where a file is located, respond to queries, and forward queries u Scalability by harnessing millions of peers u Each peer acting as both a client and server

8 Client and Server Processes l Program vs. process u Program: collection of code u Process: a running program on a host l Communication between processes u Same end host: inter-process communication l Governed by the operating system on the end host u Different end hosts: exchanging messages l Governed by the network protocols l Client and server processes u Client process: process that initiates communication u Server process: process that waits to be contacted

9 Socket: End Point of Communication l Sending message from one process to another u Message must traverse the underlying network l Process sends and receives through a “socket” u In essence, the doorway leading in/out of the house l Socket = Application Programming Interface (API) u Supports the creation of network applications socket User process Operating System Operating System

10 Identifying the Receiving Process l Sending process must identify the receiver u Name or address of the receiving end host u Identifier that specifies the receiving process l Receiving host u Destination address that uniquely identifies the host u An IP address is a 32-bit quantity l Receiving process u Host may be running many different processes u Destination port that uniquely identifies the socket u A port number is a 16-bit quantity

11 Using Ports to Identify Services Web server (port 80) Client host Server host Echo server (port 7) Service request for :80 (i.e., the Web server) Web server (port 80) Echo server (port 7) Service request for :7 (i.e., the echo server) OS Client

12 Knowing What Port Number To Use l Popular applications have well-known ports u E.g., port 80 for Web and port 25 for u Well-known ports listed at l Well-known vs. ephemeral ports u Server has a well-known port (e.g., port 80) l Between 0 and 1023 u Client picks an unused ephemeral (i.e., temporary) port l Between 1024 and l Uniquely identifying the traffic between the hosts u Two IP addresses and two port numbers u Underlying transport protocol (e.g., TCP or UDP)

13 Delivering the Data: Division of Labor l Network u Deliver data packet to the destination host u Based on the destination IP address l Operating system u Deliver data to the destination socket u Based on the protocol and destination port # l Application u Read data from the socket u Interpret the data (e.g., render a Web page)

14 Layering in the IP Protocols Internet Protocol User Datagram Protocol (UDP) Telnet HTTP SONETATM Ethernet RTPDNS FTP Transmission Control Protocol (TCP)

15 IP Packet Structure 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload

16 IP Packet Header Fields (Continued) l Protocol (8 bits) u Identifies the higher-level protocol l E.g., “6” for the Transmission Control Protocol (TCP) l E.g., “17” for the User Datagram Protocol (UDP) u Important for demultiplexing at receiving host l Indicates what kind of header to expect next IP header TCP headerUDP header protocol=6protocol=17

17 UNIX Socket API l Socket interface u Originally provided in Berkeley UNIX u Later adopted by all popular operating systems u Simplifies porting applications to different OSes l In UNIX, everything is like a file u All input is like reading a file u All output is like writing a file u File is represented by an integer file descriptor l System calls for sockets u Client: create, connect, write, read, close u Server: create, bind, listen, accept, read, write, close

18 Typical Client Program l Prepare to communicate u Create a socket u Determine server address and port number u Initiate the connection to the server l Exchange data with the server u Write data to the socket u Read data from the socket u Do stuff with the data (e.g., render a Web page) l Close the socket

19 Creating a Socket: socket() l Operation to create a socket int socket(int domain, int type, int protocol) u Returns a descriptor (or handle) for the socket u Originally designed to support any protocol suite l Domain: protocol family u PF_INET for the Internet l Type: semantics of the communication u SOCK_STREAM: reliable byte stream u SOCK_DGRAM: message-oriented service l Protocol: specific protocol u UNSPEC: unspecified u (PF_INET and SOCK_STREAM already implies TCP)

20 Connecting the Socket to the Server l Translating the server’s name to an address struct hostent *gethostbyname(char *name) u Argument: the name of the host (e.g., “ u Returns a structure that includes the host address l Identifying the service’s port number struct servent *getservbyname(char *name, char *proto) u Arguments: service (e.g., “ftp”) and protocol (e.g., “tcp”) l Establishing the connection int connect(int sockfd, struct sockaddr *server_address, socketlen_t addrlen) u Arguments: socket descriptor, server address, and address size u Returns 0 on success, and -1 if an error occurs

21 /etc/services echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null daytime 13/tcp daytime 13/udp chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp 21/tcp time 37/tcp timeserver time 37/udp timeserver

22 Sending and Receiving Data l Sending data ssize_t write(int sockfd, void *buf, size_t len) u Arguments: socket descriptor, pointer to buffer of data to send, and length of the buffer u Returns the number of characters written, and -1 on error l Receiving data ssize_t read(int sockfd, void *buf, size_t len) u Arguments: socket descriptor, pointer to buffer to place the data, size of the buffer u Returns the number of characters read (where 0 implies “end of file”), and -1 on error l Closing the socket int close(int sockfd)

23 Byte Ordering: Little and Big Endian l Hosts differ in how they store data u E.g., four-byte number (byte3, byte2, byte1, byte0) l Little endian (“little end comes first”)  Intel PCs! u Low-order byte stored at the lowest memory location u Byte0, byte1, byte2, byte3 l Big endian (“big end comes first”) u High-order byte stored at lowest memory location u Byte3, byte2, byte1, byte0 l IP is big endian (aka “network byte order”) u Use htons() and htonl() to convert to network byte order u Use ntohs() and ntohl() to convert to host order

24 Why Can’t Sockets Hide These Details? l Dealing with endian differences is tedious u Couldn’t the socket implementation deal with this u … by swapping the bytes as needed? l No, swapping depends on the data type u Two-byte short int: (byte 1, byte 0) vs. (byte 0, byte 1) u Four-byte long int: (byte 3, byte 2, byte 1, byte 0) vs. (byte 0, byte 1, byte 2, byte 3) u String of one-byte charters: (char 0, char 1, char 2, …) in both cases l Socket layer doesn’t know the data types u Sees the data as simply a buffer pointer and a length u Doesn’t have enough information to do the swapping

25 Servers Differ From Clients l Passive open u Prepare to accept connections u … but don’t actually establish one u … until hearing from a client l Hearing from multiple clients u Allow a backlog of waiting clients u... in case several try to start a connection at once l Create a socket for each client u Upon accepting a new client u … create a new socket for the communication

26 Typical Server Program l Prepare to communicate u Create a socket u Associate local address and port with the socket l Wait to hear from a client (passive open) u Indicate how many clients-in-waiting to permit u Accept an incoming connection from a client l Exchange data with the client over new socket u Receive data from the socket u Do stuff to handle the request (e.g., get a file) u Send data to the socket u Close the socket l Repeat with the next connection request

27 Server Preparing its Socket l Bind socket to the local address and port number int bind (int sockfd, struct sockaddr *my_addr, socklen_t addrlen) u Arguments: socket descriptor, server address, address length u Returns 0 on success, and -1 if an error occurs l Define how many connections can be pending int listen(int sockfd, int backlog) u Arguments: socket descriptor and acceptable backlog u Returns 0 on success, and -1 on error

28 Accepting a New Client Connection l Accept a new connection from a client int accept(int sockfd, struct sockaddr *addr, socketlen_t *addrlen) u Arguments: socket descriptor, structure that will provide client address and port, and length of the structure u Returns descriptor for a new socket for this connection l Questions u What happens if no clients are around? l The accept() call blocks waiting for a client u What happens if too many clients are around? l Some connection requests don’t get through l … But, that’s okay, because the Internet makes no promises

29 Putting it All Together socket() bind() listen() accept() read() write() Server block process request Client socket() connect() write() establish connection send request read() send response

30 Serving One Request at a Time? l Serializing requests is inefficient u Server can process just one request at a time u All other clients must wait until previous one is done l Need to time-share the server machine u Alternate between servicing different requests l Do a little work on one request, then switch to another l Small tasks, like reading HTTP request, locating the associated file, reading the disk, transmitting parts of the response, etc. u Or, start a new process to handle each request l Allow the operating system to share the CPU across processes u Or, some hybrid of these two approaches

31 Want to See Real Clients and Servers? l Apache Web server u Open source server first released in 1995 u Name derives from “a patchy server” u Software available at l Mozilla Web browser u l Sendmail u l BIND Domain Name System u Client resolver and DNS server u l …

32 Summary l Client-server paradigm u Model of communication between end hosts u Client asks, and server answers l Sockets u Simple byte-stream and messages abstractions u Common application programmable interface l Next: transport protocols u Read Sections 2.5,