the socket interface a networking application program interface
DESCRIPTION
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 WindowsTRANSCRIPT
The Socket Interface
A Networking Application Program Interface
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
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
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
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)
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
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.
Application A Application B
TCPsocket
TCPsocket
stream of bytes
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
Application A Application B
TCPsocket
TCPsocket
stream of bytes
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
Application A Application B
TCPsocket
TCPsocket
stream of bytes
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
Application A Application B
TCPsocket
TCPsocket
f e d b c a
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
UDPsocket
UDPsocket
msg msg msg
UDP Sockets:Datagrams• There is no guarantee of delivery.• Messages are not necessarily delivered in
order• Messages are kept intact
Application A Application B
UDPsocket
UDPsocket
msg msg msg
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
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)
struct sockaddr andstruct sockaddr_in
sa_len, 1 bytesa_family, 2 bytes
sa_data, 14 bytes,the address field
sockaddr sockaddr_insin_len, 1 byte
sin_family, 2bytesvalue is AF_INET
sin_port, 2 bytessin_addr, 4 bytes
8 bytes unused
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
The Socket Data Structure
protocol family:PF_INET
service: SOCK_STREAM orSOCK_DGRAM
Local IP Addr
Remote IP Addr
Local Port Number
Remote Port Number
ptr. to sock. str.
Descriptor Table Socket struct
socket descr. = n nth entry in table
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
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
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
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
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
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)
Model of Iterative Serverclient
socketServer
provideservice
listen for connection
client
socketclient
socket
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
Model of Concurrent Server
C
ServerClientsocketlisten socket
Clientsocket
Client
socketClient
socket
connects
communicates
Server clone
Server clone
Server clone
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
Model of Concurrent Server(cont.)
• The service is provided over this new connection
• This way it can service multiple clients simultaneously
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)
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
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
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
Connection Oriented Client/ServerSystem Calls
• Client– socket– connect– write– read– close
• Server– socket– bind– listen– accept– read– write– close
Connectionless Client/ServerSystem Calls
• Client– socket– [connect]– send, sendto– recv,recvfrom– close
• connect behaves differently in connectionless context
• Server– socket– bind– recv, recvfrom– send, sendto– close
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
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
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
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}
More on Getting Server Info• Function prototype for gethostbyname
struct hostent *gethostbyname(char *hostname);
hostAddr=gethostbyname(“bass.csis.gvsu.edu”);• Function prototype for getservbyname
struct servent *getservbyname(char *servname, char *protname);servPtr=getservbyname(“daytime”, “tcp”);
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
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
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.
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”);
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);
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
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
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);
Socket System Routines:bind Connless/ConnOr
• A connectionless example.• Declare variables
int sockDescr;struct sockaddr_in server ;
• Set up address structureserver.sin_family = AF_INET;server.sin_addr.s_addr = INADDR_ANY;server.sin_port = 0;
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”);
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
Socket System Routines:sendtoConnectionless
• sendto, sends data from a buffer as a single datagram, address of where to send datagram is included in parameters
• int sendto(int sockDescr, char *buffer, int bufferSize, (struct sockaddr*) &destAddr, int addrLength);
• function returns number of bytes sent or -1 as an error condition
Socket System Routines:sendtoConnectionless(cont.)
• sockDescr is the socket descriptor for the socket being used
• buffer is a buffer containing the data to be sent• bufferSize is the number of characters to be sent• destAddr is an address structure (sockaddr_in in
our case) containing address info. on destination• addrLength is size of destAddr structure
Socket System Routines:sendtoConnectionless(cont.)
• Declarations.int sockDescr, bytesSent;struct sockaddr_in server;char buffer[80];
• Assume address info on server has been obtained and placed in server structure as in earlier examples
• strcpy(buffer, “Hello there, Mr./Ms. Server!”);
Socket System Routines:sendtoConnectionless(cont.)
• bytesSent = sendto(sockDescr, buffer, strlen(buffer), (struct sockaddr *) &server, sizeof(server));if (bytesSent < 0) perror(“Client: Error in sendto.”);
Socket System Routines:recvfromConnectionless
• recvfrom, reads a single datagram from a socket into a buffer, surplus data is lost
• int recvfrom(int sockDescr, char *buffer, int bufferSize, (struct sockaddr*) &srcAddr, int &addrLength);
• function returns number of bytes read or -1 as an error condition
Socket System Routines:recvfromConnectionless(cont.)
• sockDescr is the socket descriptor for the socket being used
• buffer is a buffer for storing the data read• bufferSize is the maximum number of characters
to be read• srcAddr is an address structure (sockaddr_in in
our case) containing address info. on source• addrLength is size of srcAddr structure
Socket System Routines:recvfromConnectionless(cont.)
• Declarations.int sockDescr, bytesRead, srcAddrLength;struct sockaddr_in source;char buffer[80];
• Assume address info on server has been obtained and placed in server structure as in earlier examples
• strcpy(buffer, “Hello there, Mr./Ms. Server!”
Socket System Routines:recvfromConnectionless(cont.)
• bytesRead = recvfrom(sockDescr, buffer, 80, (struct sockaddr *) &source, &srcAddrLength);if (bytesRead < 0) perror(“Client: Error in sendto.”);buffer[bytesRead] = ‘\0’;printf(“Message received: %s\n”, buffer);
Socket System Routines:connectConnection Oriented
• connect– with SOCK_STREAM/TCP socket connect
defines the remote end point of a connection and requests a connection to that endpoint
– with SOCK_DGRAM/UDP socket connect simply records the remote endpoint host address and port no. in the socket data structure, subsequently the program can read from or write to the socket without passing the remote address components
Socket System Routines:connectConnection Oriented
• int connect(int socket_descriptor, struct sock_addr &addr, int address_length);– socket_descriptor is just what it says– &addr is the memory address of a socket address
struct which contains the address information for the remote end point
– address_length is the length of socket address struct
– returns 0 if successful, -1 if not
Socket System Routines:connectConnection Oriented
• Example:int sockDescr;struct sockaddr_in server ;
if (connect(sockDescr, (struct sockaddr *) &server, sizeof(server) ) < 0){ perror(“connect failed\n”); exit(1);}
Socket System Routines:writeConnection Oriented
• int write(int sockDescr, char &buffer, int buffer_length);
• sockDescr is socket descriptor for socket data is written to
• buffer is a buffer that contains the data• buffer_length is the number of characters to
be written from the buffer• function returns number of bytes written, -1
if and error
Socket System Routines:writeConnection Oriented
• Example.char buffer[80];int sockDescr;(Assume socket and connect calls are made)strcpy(buffer, “Hello server!”);if (write(sockDescr, &buffer, strlen(buffer) ) < 0){ perror(“Write failed”); exit(1);}
Socket System Routines:readConnection Oriented
• int read(int sockDescr, char &buffer, int chars_to_read);
• sockDescr is socket descriptor for socket data is read from
• buffer is a buffer that receives the data• chars_to_read is the number of characters to
be read into the buffer• function returns number of bytes read or -1
if an error
Socket System Routines:readConnection Oriented
• int read(int sockDescr, char &buffer, int chars_to_read);
• function returns:– number of bytes read for a normal read– 0 if other end has closed connection– -1 if an error has occurred
Socket System Routines:readConnection Oriented
• Example.char buffer[80];int sockDescr;(Assume socket and connect calls are made)if (numChars = read(sockDescr, &buffer, strlen(buffer) ) < 0){ perror(“read failed”); exit(1);}buffer[numChars] = ‘\0’;
Socket System Routines:acceptConnection Oriented
• accept, used by server, – blocks server until a connection request from a
client is received– returns a socket descriptor for a newly allocated
socket over which service can be provided• int accept(int sockDescr,
struct sockaddr *addrPtr, int addrLength);
Socket System Routines:acceptConnection Oriented(cont.)
• Example.newSock = accept(sockDescr, (struct sockaddr*) &server, sizeof(server) );
• When accept returns client is connected to the newSock socket
• The server is now free to perform another accept to get another connection request
Iterative Server’s Use of Accept• for ( ; ; )
{ newSock = accept(servSock, etc.); /* accept responds to clients connect */
Provide service getting requests an sending responses using newSock
when done close(newSock);}
• Server serves one client at a time
Concurrent Server’s Use of Accept• Server calls accept to block and wait for a
connection• Accept returns socket for providing service• Server forks a new process which provides
service on this the socket returned by accept• Main process cycles back and calls accept
again to wait for next connection
Concurrent Server’s Use of Accept• for ( ; ; )
{ newSock = accept(servSock, etc.); /* accept responds to clients connect */
fork off a child process which Closes servSock Provides service getting requests an sending responses using newSock when done close(newSock) and exit parent process closes newSock
• }• Server serves multiple clients simultaneously