Client - Server

[Spoorthi]

Issues in Client/Server Programming:


Issues in Client Programming:

lIdentifying the Server.
lLooking up a IP address.
lLooking up a well known port name.
lSpecifying a local IP address.
lUDP client design.
lTCP client design.


Identifying the Server:

lOptions:
–hard-coded into the client program.
–require that the user identify the server.
–read from a configuration file.
–use a separate protocol/network service to lookup the identity of the server.

[Spoorthi]

Identifying a TCP/IP server:


lNeed 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.




Services and Ports:

lMany services are available via “well known” addresses (names).
lThere is a mapping of service names to port numbers:
struct *servent getservbyname(
char *service, char *protocol );
lservent->s_port is the port number in network byte order.

[Spoorthi]

Specifying a Local Address:

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

haddr->port = htons(0);

give me any available port !



Local IP address:

lA client can also ask the operating system to take care of specifying the local IP address:
haddr->sin_addr.s_addr=
htonl(INADDR_ANY);





Give me the appropriate address



UDP Client Design:

lEstablish server address (IP and port).
lAllocate a socket.
lSpecify that any valid local port and IP address can be used.
lCommunicate with server (send, recv)
lClose the socket.

[Spoorthi]

Connected mode UDP:

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




TCP Client Design:

lEstablish server address (IP and port).
lAllocate a socket.
lSpecify that any valid local port and IP address can be used.
lCall connect()
lCommunicate with server (read,write).
lClose the connection.

[Spoorthi]

Closing a TCP socket:

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




Partial Close:

lOne solution is for the client to shut down only it’s writing end of the socket.
l
lThe 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!

[Spoorthi]

TCP sockets programming:

lCommon problem areas:
–null termination of strings.
–reads don’t correspond to writes.
–synchronization (including close()).
–ambiguous protocol.




TCP Reads:

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

[Spoorthi]

Server Design:

Iterative

Connectionless

Iterative

Connection-Oriented

Concurrent

Connectionless

Concurrent

Connection-Oriented

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

[Spoorthi]

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:

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



Messages can be duplicated!


The Dangers of Statefullness:

lClients can go down at any time.
lClient hosts can reboot many times.
lThe network can lose messages.
lThe network can duplicate messages.

[Spoorthi]

Concurrent Server Design Alternatives:

One child per client
Spawn one thread per client
Preforking multiple processes
Prethreaded Server



One child per client:

lTraditional Unix server:
–TCP: after call to accept(), call fork().
–UDP: after recvfrom(), call fork().
–Each process needs only a few sockets.
–Small requests can be serviced in a small amount of time.
lParent process needs to clean up after children!!!! (call wait() ).




One thread per client:

lAlmost like using fork - call pthread_create instead.
lUsing threads makes it easier (less overhead) to have sibling processes share information.
lSharing information must be done carefully (use pthread_mutex)

[Spoorthi]

Prefork()’d Server:

lCreating a new process for each client is expensive.
l
lWe can create a bunch of processes, each of which can take care of a client.
l
lEach child process is an iterative server.




Prefork()’d TCP Server:

lInitial process creates socket and binds to well known address.
lProcess now calls fork() a bunch of times.
lAll children call accept().
lThe next incoming connection will be handed to one child.




Preforking:

lAs the book shows, having too many preforked children can be bad.
lUsing dynamic process allocation instead of a hard-coded number of children can avoid problems.
lThe parent process just manages the children, doesn’t worry about clients.
l