EECS 122 Introduction to Computer Networks Sockets Programming

  • Slides: 33
Download presentation
EECS 122: Introduction to Computer Networks Sockets Programming Computer Science Division Department of Electrical

EECS 122: Introduction to Computer Networks Sockets Programming Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley, CA 94720 -1776 EECS 122 - UCB Katz, Stoica F 04

Outline § § § Socket API motivation, background Names, addresses, presentation API functions I/O

Outline § § § Socket API motivation, background Names, addresses, presentation API functions I/O multiplexing Some “find-the-bug” mini-C-quizzes Katz, Stoica F 04 2

Quiz! § What is wrong with the following code? void alpha () { rtgptr

Quiz! § What is wrong with the following code? void alpha () { rtgptr = rtg_headptr; while (ptr != NULL) { rtg_check (ptr); ptr = ptr->nextptr; } } struct routeptr { int value; struct routeptr *nextptr; } typedef struct routeptr rtgptr; void rtg_check (rtgptr ptr) { if (ptr->value == 0) free (ptr); } Katz, Stoica F 04 3

Motivation § Applications need Application Programming Interface (API) to use the network application transport

Motivation § Applications need Application Programming Interface (API) to use the network application transport API network data-link physical § API: set of function types, data structures and constants • Allows programmer to learn once, write anywhere • Greatly simplifies job of application programmer Katz, Stoica F 04 4

Sockets (1) § What exactly are sockets? - An endpoint of a connection -

Sockets (1) § What exactly are sockets? - An endpoint of a connection - A socket is associated with each end-point (end-host) of a connection § Identified by IP address and port number § Berkeley sockets is the most popular network API - Runs on Linux, Free. BSD, OS X, Windows - Fed/fed off popularity of TCP/IP Katz, Stoica F 04 5

Sockets (2) § Similar to UNIX file I/O API (provides file descriptor) § Based

Sockets (2) § Similar to UNIX file I/O API (provides file descriptor) § Based on C, single threaded model - Does not require multiple threads § Can build higher-level interfaces on top of sockets - e. g. , Remote Procedure Call (RPC) Katz, Stoica F 04 6

Types of Sockets (1) § Different types of sockets implement different service models -

Types of Sockets (1) § Different types of sockets implement different service models - Stream v. s. datagram § Stream socket (aka TCP) - § Connection-oriented (includes establishment + termination) Reliable, in order delivery At-most-once delivery, no duplicates E. g. , ssh, http Datagram socket (aka UDP) - Connectionless (just data-transfer) - “Best-effort” delivery, possibly lower variance in delay - E. g. , IP Telephony, streaming audio Katz, Stoica F 04 7

Types of Sockets (2) § § How does application programming differ between stream and

Types of Sockets (2) § § How does application programming differ between stream and datagram sockets? Stream sockets - No need to packetize data - Data arrives in the form of a byte-stream - Receiver needs to separate messages in stream TCP sends messages joined together, ie. “Hi there!Hope you are well” application transport network data-link physical User application sends messages “Hi there!” and “Hope you are well” separately Katz, Stoica F 04 8

Types of Sockets (3) § Stream socket data separation: - Use records (data structures)

Types of Sockets (3) § Stream socket data separation: - Use records (data structures) to partition data stream - How do we implement variable length records? size of A fixed length record B C fixed length record 4 variable length record - What if field containing record size gets corrupted? • Not possible! Why? Katz, Stoica F 04 9

Types of Sockets (4) § Datagram sockets - User packetizes data before sending -

Types of Sockets (4) § Datagram sockets - User packetizes data before sending - Maximum size of 64 Kbytes - Further packetization at sender end and depacketization at receiver end handled by transport layer - Using previous example, “Hi there!” and “Hope you are well” will definitely be sent in separate packets at network layer Katz, Stoica F 04 10

Naming and Addressing § IP version 4 address - Identifies a single host -

Naming and Addressing § IP version 4 address - Identifies a single host - 32 bits - Written as dotted octets • e. g. , 0 x 0 a 000001 is 10. 0. 0. 1 § Host name - Identifies a single host - Variable length string - Maps to one or more IP address • e. g. , www. berkeley. edu - Gethostbyname translates name to IP address § Port number - Identifies an application on a host - 16 bit unsigned number Katz, Stoica F 04 11

Presentation increasing memory addresses little-endian address A +1 address A high-order byte low-order byte

Presentation increasing memory addresses little-endian address A +1 address A high-order byte low-order byte 16 -bit value big-endian (network byte-order) low-order byte high-order byte Katz, Stoica F 04 12

Byte Ordering Solution uint 16_t uint 32_t § htons(uint 16_t htonl(uint 32_t ntohs(uint 16_t

Byte Ordering Solution uint 16_t uint 32_t § htons(uint 16_t htonl(uint 32_t ntohs(uint 16_t ntohl(uint 32_t host 16 bitvalue); host 32 bitvalue); net 16 bitvalue); net 32 bitvalue); Use for all numbers (int, short) to be sent across network - Including port numbers, but not IP addresses Katz, Stoica F 04 13

Quiz! § What is wrong with the following code? int factorial (int a) {

Quiz! § What is wrong with the following code? int factorial (int a) { /* we want to if (a == 0 || a == 1) return factorial return 1; of a */ if (a < 0) return -1; return a * factorial (a-1); } Katz, Stoica F 04 14

Stream Sockets § § § Implements Transmission Control Protocol (TCP) Does NOT set up

Stream Sockets § § § Implements Transmission Control Protocol (TCP) Does NOT set up virtual-circuit! Sequence of actions: socket () reuse () bind () initialize connect () listen () accept () establish send () recv () socket () data xfer time recv () send () close () Client Server terminate Katz, Stoica F 04 15

Initialize (Client + Server) int sock; if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0)

Initialize (Client + Server) int sock; if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { perror("socket"); printf("Failed to create socketn"); abort (); } § Handling errors that occur rarely usually consumes most of systems code - Exceptions (e. g. , in java) helps this somewhat Katz, Stoica F 04 16

Initialize (Server reuse addr) § § § After TCP connection closes, waits for 2

Initialize (Server reuse addr) § § § After TCP connection closes, waits for 2 MSL, which is twice maximum segment lifetime (from 1 to 4 mins) Segment refers to maximum size of a packet Port number cannot be reused before 2 MSL But server port numbers are fixed must be reused Solution: int optval = 1; if ((sock = socket (AF_INET, SOCK_STREAM, 0)) < 0) { perror ("opening TCP socket"); abort (); } if (setsockopt (sock, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof (optval)) <0) { perror (“reuse address"); abort (); } Katz, Stoica F 04 17

Initialize (Server bind addr) § Want port at server end to use a particular

Initialize (Server bind addr) § Want port at server end to use a particular number struct sockaddr_in sin; memset (&sin, 0, sizeof (sin)); sin_family = AF_INET; sin_addr. s_addr = IN_ADDR; sin_port = htons (server_port); if (bind(sock, (struct sockaddr *) &sin, sizeof (sin)) < 0) { perror(“bind"); printf("Cannot bind socket to addressn"); abort(); } Katz, Stoica F 04 18

Initialize (Server listen) § § Wait for incoming connection Parameter BACKLOG specifies max number

Initialize (Server listen) § § Wait for incoming connection Parameter BACKLOG specifies max number of established connections waiting to be accepted (using accept()) if (listen (sock, BACKLOG) < 0) { perror (“error listening"); abort (); } Katz, Stoica F 04 19

Establish (Client) struct sockaddr_in sin; struct hostent *host = gethostbyname (argv[1]); unsigned int server_addr

Establish (Client) struct sockaddr_in sin; struct hostent *host = gethostbyname (argv[1]); unsigned int server_addr = *(unsigned long *) host->h_addr_list[0]; unsigned short server_port = atoi (argv[2]); memset (&sin, 0, sizeof (sin)); sin_family = AF_INET; sin_addr. s_addr = server_addr; sin_port = htons (server_port); if (connect(sock, (struct sockaddr *) &sin, sizeof (sin)) < 0) { perror("connect"); printf("Cannot connect to servern"); abort(); } Katz, Stoica F 04 20

Establish (Server) § Accept incoming connection int addr_len = sizeof (addr); int sock; sock

Establish (Server) § Accept incoming connection int addr_len = sizeof (addr); int sock; sock = accept (tcp_sock, (struct sockaddr *) &addr, &addr_len); if (sock < 0) { perror ("error accepting connection"); abort (); } Katz, Stoica F 04 21

Sending Data Stream int send_packets (char *buffer, int buffer_len) { sent_bytes = send (sock,

Sending Data Stream int send_packets (char *buffer, int buffer_len) { sent_bytes = send (sock, buffer_len, 0); if (send_bytes < 0) perror (“send”); return 0; } Katz, Stoica F 04 22

Receiving Data Stream int receive_packets(char *buffer, int buffer_len, int *bytes_read) { int left =

Receiving Data Stream int receive_packets(char *buffer, int buffer_len, int *bytes_read) { int left = buffer_len - *bytes_read; received = recv(sock, buffer + *bytes_read, left, 0); if (received < 0) { perror ("Read in read_client"); printf("recv in %sn", __FUNCTION__); } if (received == 0) { /* occurs when other side closes connection */ return close_connection(); } *bytes_read += received; while (*bytes_read > RECORD_LEN) { process_packet(buffer, RECORD_LEN); *bytes_read -= RECORD_LEN; memmove(buffer, buffer + RECORD_LEN, *bytes_read); } return 0; } Katz, Stoica F 04 23

Quiz! § We have the following packet header format (the numbers denote field size

Quiz! § We have the following packet header format (the numbers denote field size in bytes) : length type source addr dest addr 2 1 4 4 § What is wrong with the code below? typedef struct _pkt_hdr_ { words aligned in memory: begins unsigned short length; at address that is a multiple of bytes char type; in word unsigned int src_addr; unsigned int dest_addr; source dest length type ? ? addr } pkt_hdr, *pkt_hdrptr; . . . 2 1 1 4 4 char buffer[256]; pkt_hdr header; /* assume fields filled in properly here */ memcpy (buffer, &header, sizeof (header)); send (sock, buffer, sizeof (header), 0); Katz, Stoica F 04 24

Datagram Sockets § Similar to stream sockets, except: - Sockets created using SOCK_DGRAM instead

Datagram Sockets § Similar to stream sockets, except: - Sockets created using SOCK_DGRAM instead of SOCK_STREAM - No need for connection establishment and termination - Uses recvfrom() and sendto() in place of recv() and send() respectively - Data sent in packets, not byte-stream oriented Katz, Stoica F 04 25

How to handle multiple connections? § Where do we get incoming data? - Stdin

How to handle multiple connections? § Where do we get incoming data? - Stdin (typically keyboard input) - All stream, datagram sockets - Asynchronous arrival, program doesn’t know when data will arrive § Solution: I/O multiplexing using select () - Coming up soon § Solution: I/O multiplexing using polling - Very inefficient § Solution: multithreading - More complex, requires mutex, semaphores, etc. - Not covered Katz, Stoica F 04 26

I/O Multiplexing: Polling get data from socket get user input int opts = fcntl

I/O Multiplexing: Polling get data from socket get user input int opts = fcntl (sock, F_GETFL); first get current if (opts < 0) { socket option settings perror ("fcntl(F_GETFL)"); abort (); } then adjust settings opts = (opts | O_NONBLOCK); if (fcntl (sock, F_SETFL, opts) < 0) { finally store settings perror ("fcntl(F_SETFL)"); back abort (); } while (1) { if (receive_packets(buffer, buffer_len, &bytes_read) != 0) { break; } if (read_user(user_buffer, user_buffer_len, &user_bytes_read) != 0) { break; } } Katz, Stoica F 04 27

I/O Multiplexing: Select (1) § Select() - Wait on multiple file descriptors/sockets and timeout

I/O Multiplexing: Select (1) § Select() - Wait on multiple file descriptors/sockets and timeout - Application does not consume CPU cycles while waiting - Return when file descriptors/sockets are ready to be read or written or they have an error, or timeout exceeded § Advantages - Simple - More efficient than polling § Disadvantages - Does not scale to large number of file descriptors/sockets - More awkward to use than it needs to be Katz, Stoica F 04 28

I/O Multiplexing: Select (2) fd_set read_set; struct timeval time_out; while (1) { set up

I/O Multiplexing: Select (2) fd_set read_set; struct timeval time_out; while (1) { set up FD_ZERO (read_set); FD_SET (stdin, read_set); /* stdin is typically 0 */ parameters FD_SET (sock, read_set); for select() time_out. tv_usec = 100000; time_out. tv_sec = 0; select_retval = select(MAX(stdin, sock) + 1, &read_set, NULL, run select() NULL, &time_out); if (select_retval < 0) { perror ("select"); abort (); } if (select_retval > 0) { if (FD_ISSET(sock, read_set)) { interpret if (receive_packets(buffer, buffer_ len, &bytes_read) != 0) { break; result } if (FD_ISSET(stdin, read_set)) { if (read_user(user_buffer, user_buffer_len, &user_bytes_read) != 0) { break; } } Katz, Stoica F 04 29

Common Mistakes + Hints § Common mistakes: - C programming • Use gdb •

Common Mistakes + Hints § Common mistakes: - C programming • Use gdb • Use printf for debugging, remember to do fflush(stdout); - Byte-ordering - Use of select() - Separating records in TCP stream - Not knowing what exactly gets transmitted on the wire • Use tcpdump / Ethereal § Hints: - Use man pages (available on the web too) - Check out WWW, programming books Katz, Stoica F 04 30

Project Orion (1) § § Basically a messaging program Client registers with server, after

Project Orion (1) § § Basically a messaging program Client registers with server, after which server forwards messages to other clients in the same session Katz, Stoica F 04 31

Project Orion (2) § First project: write client and server code Specs at http:

Project Orion (2) § First project: write client and server code Specs at http: //www. eecs. berkeley. edu/~ct-ee/Orion § Divided into 2 checkpoints: § - Checkpoint 1: client code, due 9/24/03, 3. 50 pm - Checkpoint 2: server code, due 10/1/03, 3. 50 pm § Some details in project 1 may seem unnecessary, but will be used in project 3 - Eg. inclusion of server user id in packet header - Eg. reserved fields (may also be used for extra features) Katz, Stoica F 04 32

Project Orion (3) § Use both TCP and UDP sockets - UDP used in

Project Orion (3) § Use both TCP and UDP sockets - UDP used in control plane (operations that install state, or information, in system) - TCP used in data plane (operations that are performed directly on the data messages) § Constants used in project - found in header file orion. h - orion. h MUST NOT BE CHANGED § § Read the specifications carefully, clarify immediately when in doubt Hopefully, project 3 specs released within 2 weeks’ time - Preferably, extra features should be implemented in project 3 - Spend more time on project 3 (6 weeks to do it) Katz, Stoica F 04 33