The Socket Interface

1. The Socket Interface A Networking Application Program Interface

2. API: Application Program Interface • An API is an interface available to application level programmers to some low level resource or service • The interface consists of program elements that the programmer can use in his or her program to access the resource or service • These generally consist of data structures and procedures

3. The Socket Interface • Provides a way for one program to establish a network connection with another program • Originated in the Berkeley Software Distribution (BSD) version of Unix • Provides access to underlying network protocols • Patterned after the Unix file system and as much as possible shares features with it • Socket interface extended to other environments, in particular Windows

4. Sockets and TCP/IP • The interface is general enough to provide access to multiple protocol stacks • We will restrict our attention to its use in accessing the TCP/IP protocols • The socket API provides the programmer with system calls for requesting that TCP set up a connection with or that UDP send a message to another program in another machine

5. Sockets and TCP/IP(cont.) • Recall that TCP and UDP are both transport level protocols within the TCP/IP suite • TCP provides a connection oriented service • sets up a network connection with another host on the network • monitors packets sent across this connection and provides retransmission of missing packets and reordering of out of order packets • provides reliable disconnection (as much as possible)

6. Sockets and TCP/IP(cont.) • UDP provides a connectionless service • communication consists of isolated packets called datagrams • UDP relies on IP to make a best effort to deliver the packet • UDP provides no acknowledgement, retransmission, or reordering service • For TCP the endpoints of a connection and for UDP the source and destination are identified by a host address-port number pair

7. TCP Sockets:Streams • When sockets are used over TCP the sockets are viewed as the endpoints of a bi-directional stream of bytes between the two application programs. stream of bytes Application A Application B socket socket TCP TCP

8. TCP Sockets:Streams • To send data to the other application the program writes to the socket, to get data from the other application the program reads from the socket stream of bytes Application A Application B socket socket TCP TCP

9. TCP Sockets:Streams • The socket is required to deliver the bytes to one end in the order they were read from the other end but is not required keep the “message” boundaries intact stream of bytes Application A Application B socket socket TCP TCP

10. TCP Sockets:Streams • Application A writes “abc” on one write and “def” on a second write • When application B does a read it may receive “abcdef” on one read, or “ab” on one read and “cdef” on a second f e d b c a Application A Application B socket socket TCP TCP

11. UDP Sockets:Datagrams • When sockets are used over UDP the sockets are viewed as endpoints of a bi-directional stream of messages sent between the applications Application A Application B socket socket UDP UDP msg msg msg

12. UDP Sockets:Datagrams • There is no guarantee of delivery. • Messages are not necessarily delivered in order • Messages are kept intact Application A Application B socket socket UDP UDP msg msg msg

13. What the Socket Interface Provides • The socket interface provides • a data structure for storing protocol information about the source and destination endpoints (for TCP/IP the host addresses and port numbers) • service calls to: • obtain the data to be placed in the data structure • request a socket from the operating system • place the socket in various states required by a client or server • send and receive data using the socket • close the socket releasing os resources

14. The Socket Address Data Structures • There is a general socket address struct data type named sockaddr • This data structure has a very general address field • Each specific protocol has its own socket address structure that overlays the address field with its own address structure • For TCP/IP this structure type is sockaddr_in (in for internet protocols)

15. struct sockaddr andstruct sockaddr_in sockaddr sockaddr_in sa_len, 1 byte sin_len, 1 byte sa_family, 2 bytes sin_family, 2bytes value is AF_INET sin_port, 2 bytes sa_data, 14 bytes, the address field sin_addr, 4 bytes 8 bytes unused

16. The Socket Data Structure • A socket is identified by a socket descriptor • A socket descriptor is an integer • This integer is an index into a table of pointers used for files, devices, and sockets • The pointer points to a data structure that describes the file, device or socket • In the case of a socket this pointer points to a socket structure

17. The Socket Data Structure Socket struct Descriptor Table protocol family:PF_INET socket descr. = n nth entry in table service: SOCK_STREAM or SOCK_DGRAM Local IP Addr ptr. to sock. str. Remote IP Addr Local Port Number Remote Port Number

18. The Connection Problem • How do two programs connect with each other? • In order to connect with each other they must • each know the host address on which the other process is running • each know the port number the other is using • each have set up sockets using these addresses and port numbers • each have made a well timed request to connect to the other

19. The Client/Server Model:A Solution to the Connection Problem • The server is always running, waiting for a connection request at an address and port known to the client • The client requests a connection to the server, sending its address and port number • The server accepts the connection and communication occurs • One end or the other closes the connection

20. How does the client know? • Sometimes the server runs on every machine so the client just needs to know the port number • Some services run on well known ports • Unix contains service calls to find the address of a host and the port number for a service • If the above does not apply the client must be told

21. Categories of Servers • Connection oriented or connectionless • connection oriented, set up a connection • connectionless, just send messages • Iterative and concurrent • iterative, can just service one client at a time • concurrent, can service multiple clients simultaneously

22. Categories of Servers (cont.) • Iterative servers should be used when the service time is short, e.g., time of day service • Concurrent servers should be used when the service time is long, e.g., telnet or ftp • General rule • connection oriented servers are concurrent • iterative servers are connectionless

23. Categories of Servers (cont.) • There are different ways servers can provide concurrency • use the operating systems concurrency mechanism (this is best) • handle the concurrency itself (more complex program)

24. Model of Iterative Server client socket client socket Server client socket listen for connection provide service

25. Model of Iterative Server • The server establishes a permanent socket using a known port number which it uses to accept connections • A client requests a connection to this port number, usually using a dynamically assigned port number • The server provides the service on another socket • Other clients must wait until connected client has been served

26. Model of Concurrent Server Server Client connects socket listen socket C Client Server clone socket Client communicates Server clone socket Client Server clone socket

27. Model of Concurrent Server • The server uses a known socket ( the listen socket in the diagram) which it uses to accept connection requests • For each connection request it dynamically creates: • a new server process to provide the service and • a new socket for the client to connect to • The service is provided over this new connection • After setting up a client the server listens for more connections

28. Model of Concurrent Server(cont.) • The service is provided over this new connection • This way it can service multiple clients simultaneously

29. Socket System Calls • socket, allocate a socket and return a socket descriptor identifying the socket • connect, establish a connection to the specified endpoint, dynamically allocate a local port no. for the local endpoint • bind, bind a particular port no. to the local endpoint (could also bind a particular host address but that is not usually done)

30. Socket System Calls • listen • place the socket in passive listening mode waiting for a request to connect • set a queue length for pending connect requests • accept • indicate the process is willing to accept a connection • block the process until a connection is made • allocate a new socket to the connection • return the socket descriptor for the new socket

31. Socket System Calls • close, closes the socket connection and deallocates resources allocated to the socket • read • treats data from socket as a byte stream • read data from a socket into a buffer • used in connection oriented situations • write • treats data going to socket as a byte stream • write data from a buffer to a socket • used in connection oriented situations

32. Socket System Calls • recv, recvfrom • get a message from the socket • used in connectionless situations • send, sendto • send a message out the socket • used in connectionless situations • shutdown, shuts down data flow in one direction without closing the socket

33. Client socket connect write read close Server socket bind listen accept read write close Connection Oriented Client/ServerSystem Calls

34. Client socket [connect] send, sendto recv,recvfrom close connect behaves differently in connectionless context Server socket bind recv, recvfrom send, sendto close Connectionless Client/ServerSystem Calls

35. Getting Information About the Server • There are two items of information we generally need to obtain about are server • The address of the machine it is running on • The port number on which the service is offered • This information can be obtained by calls to two system routines • gethostbyname, takes the domain name in the form of a string and returns the address

36. Getting Server Info (cont.) • getservbyname, takes the name of the service as a string and returns the port number • The information is returned in a data structure and the functions return pointers to those data structures • getservbyname only works for services using well known ports

37. hostent, The Host Info. Struct struct hostent { char *h_name; //official name of host char **h_aliases; //list of aliases for host int h_addrtype; //hos t address type int h_length; //length of address in bytes char **h_addr_list; //list of addresses from domain //name server }; #define h_addr h_addr_list[0]; //short name for the first address in the list

38. servent, The Service Struct struct servent { char *s_name; //official service name char **s_aliases; //other aliases int s_port; //port no. for this service char *s_proto; //protocol to use }

39. More on Getting Server Info • Function prototype for gethostbynamestruct hostent *gethostbyname(char *hostname);hostAddr=gethostbyname(“bass.csis.gvsu.edu”); • Function prototype for getservbynamestruct servent *getservbyname(char *servname, char *protname);servPtr=getservbyname(“daytime”, “tcp”);

40. Command Line Arguments • The domain name of the host, the service requested, port number and other aspects of the service can be specified by command line arguments • Command line arguments are strings that are typed after the invocation of the program

41. Command Line Arguments (cont.) • Example of using command line arguments%client carp.csis.gvsu.edu echo • client is the name of the program being invoked, this is the first argument • carp.csis.etc. is the name of the host • echo is the name of the service

42. Command Line Arguments (cont.) • Command line arguments are parameters for the main function • void main(int argc, char *argv[]) • argc gives the number of command line arguments including the program name • argv is an array of strings consisting of the various command line arguments, argc is the length of the array argv • program name is argv[0], next arg is argv[1], etc.

43. Command Line Arguments (cont.) • %client carp.csis.gvsu.edu echo • argc = 3, argv[0] = “client”, argv[1] = carp.csis.gvsu.edu, argv[2] = “echo” • struct hostent *hostData;struct servemt *serviceData;hostData = gethostbyname(argv[1]);serviceData = getservbyname(argv[2], “tcp”);

44. Placing Server Data in Server Address Struct • struct hostent * hostData;struct servent *serviceData;struct sockaddr_in serverAddr; • memset(&serverAddr, 0, sizeof(serverAddr); • serverAddr.sin_family = AF_INET;serverAddr.sin_port = serviceData->s_port;memcopy(&serverAddr.sin_addr, hostData -> h_addr, hostData -> h_length);

45. Socket System Routines:socketConnless/ConnOr • socket, allocates a socket and accompanying struct to hold data about the socket • returns a socket descriptor, and integer index into the descriptor table that identifies a pointer to the struct • int socket(int family, int type, int protocol); • family = PF_INET • type = SOCK_STREAM or SOCK_DGRAM • protocol = 0 indicates to use default protocol for type

46. Socket System Routines:socket Connless/ConnOr • Examples: • sd = socket(PF_INET, SOCK_STREAM, 0); • sd = socket(PF_INET, SOCK_DGRAM, 0); • The first call will use TCP as the protocol • The second call will use UDP as the protocl

47. Socket System Routines:bind Connless/ConnOr • bind, specifies the host address and port no. portion of the socket address structure. • for a client this fixes the address the server responds to during the current session • for a server this fixes the port no. on which the service is offered and to which clients request connection • int bind((int socket_descriptor, struct sock_addr &addr, int address_length);

48. Socket System Routines:bind Connless/ConnOr • A connectionless example. • Declare variablesint sockDescr;struct sockaddr_in server ; • Set up address structureserver.sin_family = AF_INET;server.sin_addr.s_addr = INADDR_ANY;server.sin_port = 0;

49. Socket System Routines:bind Connless/ConnOr • Calling the bind function.retVal = bind(sockDescr, (struct sockaddr*) & server , sizeof(server) );if (retVal < 0) perror(“Error on bind.\n”);

50. Socket System Routines:closeConless/ConnOr • int close(int sockDescr); • sockDescr is the socket descriptor for the socket being closed • The socket is closed, allocated resources are deallocated • returns 0 if successful, -1 if an error • the only error is an invalid socket descriptor value