Client/Server - Sockets Programming

Issues

Issues in Client Programming

• Identifying the Server.
• Looking up a IP address.
• Looking up a well known port name.
• Specifying a local IP address.
• UDP client design.
• TCP client design.

Identifying the Server

Options:

• hard-coded into the client program.
• require that the user identify the server.
• read from a configuration file.
• use a separate protocol/network service.

Identifying a TCP/IP server.

• Need an IP address, protocol and port.
• We often use host names instead of IP addresses.
• usually the protocol (UDP vs. TCP) is not specified by the user.
• often the port is not specified by the user.

Host Names

• IP Addresses are great for computers
• IP address includes information used for routing.
• IP addresses are tough for humans to remember.
• IP addresses are impossible to guess. – ever guessed at the name of a WWW site?

The Domain Name System

• The domain name system is usually used to translate a host name into an IP address .
• Domain names comprise a hierarchy so that names are unique, yet easy to remember.

DNS Hierarchy

Looking up a Domain Name

• We want to convert a Domain Name to an IP address:

struct *hostent gethostbyname( char *name );

• gethostbyname() returns the address of a structure that contains the IP address in network byte order.

Services and Ports

• Many services are available via “well known” addresses (names).
• There is a mapping of service names to port numbers:

struct *servent getservbyname( char *service, char *protocol );

• servent->s_port is the port number in network byte order.

Specifying a Local Address

• When a client creates and binds a socket it must specify a local port and IP address.
• Typically a client doesn’t care what port it is on:

haddr->port = 0;

Local IP address

• A client can also ask the operating system to take care of specifying the local IP address:

haddr->sin_addr.s_addr= INADDR_ANY;

UDP Client Design

1. Establish server address (IP and port).
2. Allocate a socket.
3. Specify that any valid local port and IP address can be used.
4. Communicate with server (send, recv)
5. Close the socket.

Connected mode UDP

• A UDP client can call connect() to establish the address of the server.
• The UDP client can then use read() and write() or send() and recv().
• A UDP client using a connected mode socket can only talk to one server (using the connected-mode socket).

TCP Client Design

1. Establish server address (IP and port).
2. Allocate a socket.
3. Specify that any valid local port and IP address can be used.
4. Call connect() l Communicate with server (read,write).
5. Close the connection.

connect()

retcode = connect( int s, struct sockaddr *addr, int addrlen);

• The return value is 0 if OK, -1 means there was an error.
• If connect is sucessfull the socket is ready for read() and write().

Closing a TCP socket

• Many TCP based application protocols support multiple requests and/or variable length requests over a single TCP connection.
• How does the server known when the client is done (and it is OK to close the socket) ?

Partial Close

• One solution is for the client to shut down only it’s writing end of the socket.
• The shutdown() system call provides this function.

shutdown( int s, int direction);

• direction can be 0 to close the reading end or 1 to close the writing end.
• shutdown sends info to the other process!

TCP sockets programming

• Common problem areas:

• null termination of strings.
• reads don’t correspond to writes.
• synchronization (including close()).
• ambiguous protocol.

TCP Reads

• Each call to read() on a TCP socket returns any available data (up to a maximum).
• TCP buffers data at both ends of the connection.
• You must be prepared to accept data 1 byte at a time from a TCP socket!

Reading n bytes

int readn( int sd, char *buf, int n) { 

int i=0; 

int cnt; 

while ( (i0) i+=cnt; return i; } 

Reading a line

int readline( int sd, char *buf, int max) {

int i=0;

if (read(sd,buf,1)!=1)

return(0);

while (( buf[i]!=‘\n’) && (i<max) ) {

i++;

if (read(sd,buf+i,1)!=1) return(0);

}

buf[i]=0;

return(i);

Server Design

Concurrent vs. Iterative

• An iterative server handles a single client request at one time.
• A concurrent server can handle multiple client requests at one time.

Concurrent vs. Iterative

• Concurrent
• Large or variable size requests
• Harder to program
• Typically uses more system resources

• Iterative
• Small, fixed size requests
• Easy to program

Connectionless vs. Connection-Oriented

• Connection-Oriented
• EASY TO PROGRAM
• transport protocol handles the tough stuff.
• requires separate socket for each connection.
• Connectionless
• less overhead
• no limitation on number of clients

Statelessness

• State: Information that a server maintains about the status of ongoing client interactions.
• Connectionless servers that keep state information must be designed carefully!

The Dangers of Statefullness

• Clients can go down at any time.
• Clients can reboot many times.
• The network can lose messages.
• The network can duplicate messages.