Server Design

Discuss Design issues for ServersReview Server Creation in Linux

Server Software Design

• Concurrent Vs. Iterative– Concurrent servers support multiple clients

concurrently (may or may not use concurrent processes)

– Iterative servers support a single client at a time. (Much easier to build, but usually much less efficient)

CS423 - cotter 2

Server Software Design

• Concurrent Vs. Iterative– Concurrent servers support multiple clients

concurrently (may or may not use concurrent processes)

– Iterative servers support a single client at a time. (Much easier to build, but usually much less efficient)

• Connection-Oriented Vs. Connectionless– Connection Oriented access is provided through TCP

which provides all of the reliability for the access.– Connectionless access is provided through UDP, and

requires the application to provide reliability.

CS423 - cotter 3

Server Software Design

• Stateless Vs. Stateful Servers– Stateful servers maintain status of ongoing client

communications. Use of state information can allow more efficient communication (less information needed in each message), but it does open up the possibility of state dependencies if not carefully designed into the server.

– Stateless servers rely on the client to provide all of the information needed for each request. Easier to design, but generally less efficient.

CS423 - cotter 4

Stateless Vs. Stateful ServersExample

• Client queries server for file information (ftp, database search, etc.)• Stateless model:

– query includes filename, offset, # of bytes to read

CS423 - cotter 5

Stateless Vs. Stateful ServersExample

• Client queries server for file information (ftp, database search, etc.)• Stateless model:

– query includes filename, offset, # of bytes to read• Stateful model:

– server maintains table of client info current queries containing filename, current offset

– client sends request to read # of bytes– server accesses buffer for info, if available,or disk

file.

CS423 - cotter 6

Stateless Vs. Stateful Servers

CS423 - cotter 7

Filename: XOffset: 512Buffer Pointer:

Filename: YOffset: 1024Buffer Pointer:

hash(IP, port)

Buffer for file X , pointer at 512

Buffer for file Y , pointer at 1024

Basic Server Types

CS423 - cotter 8

Iterativeconnectionless

Iterative connection-oriented

Concurrentconnectionless

Concurrentconnection-oriented

Basic Server Types

CS423 - cotter 9

Iterativeconnectionless

Iterative connection-oriented

Concurrentconnectionless

Concurrentconnection-oriented

Iterative Connection-Oriented Server

• Create a socket & bind to the port for the service being offered.

• Place the socket in passive mode (listen)• Accept the next connection request from the socket

and obtain a new socket for the connection.• Repeatedly send a request from client, formulate a

response, and send response back to client.• When finished with a client, close the connection &

return to accept mode, waiting for a new connection.

CS423 - cotter 10

Iterative Connectionless Server

• Create a socket and bind to the well-known address for the service being offered.

• Repeatedly read the next request from a client, formulate a response, and send a reply back to the client according to the application protocol.

CS423 - cotter 11

Concurrent Connectionless Server

• (P) Create a socket & bind to the port for the service being offered.

• (P) Repeatedly call recvfrom to receive the next request from client, & create a new child process

• (c) Receive a specific request upon creation as well as access to the socket.

• (c) Form a reply according to application protocol and send it back to client using sendto.

• (c) Terminate child process upon completion of task

CS423 - cotter 12

Concurrent Connection-Oriented Server

• (P) Create a socket & bind to the port for the service offered. Leave the socket unconnected

• (P) Place the socket in passive mode (listen)• (P) Repeatedly call accept to receive the next

request from client, & create new child process• (c) Receive a connection request upon creation• (c) Interact with client (read request(s) & send(s))• (c) Terminate child process upon completion of

task

CS423 - cotter 13

Server Issues

• Request processing time Vs. Observed response time

CS423 - cotter 14

Server Issues

• Request processing time Vs. Observed response time

• Use of INADDR_ANY to receive datagrams from any IP address.

CS423 - cotter 15

Server Issues

• Request processing time Vs. Observed response time

• Use of INADDR_ANY to receive datagrams from any IP address.

• Connectionless communications:– ans = sendto(s, buf, buflen, flags, toaddr,

toaddrlen)– ans = recvfrom(s, buf, buflen, flags, toaddr,

toaddrlen)

CS423 - cotter 16

Server Issues

• Request processing time Vs. Observed response time

• Use of INADDR_ANY to receive datagrams from any IP address.

• Connectionless communications:– ans = sendto(s, buf, buflen, flags, toaddr, toaddrlen)– ans = recvfrom(s, buf, buflen, flags, toaddr, toaddrlen)

• Use of exec for child processes

CS423 - cotter 17

Real vs. Apparent Concurrency

CS423 - cotter 18

Multiple low duty cycle clients can be handled by a Single thread

Apparent vs Real Concurrency

• Create a socket and bind to the well-known address for the service being offered. Add socket to the list of those on which I/O is possible

CS423 - cotter 19

Apparent vs Real Concurrency

• Create a socket and bind to the well-known address for the service being offered. Add socket to the list of those on which I/O is possible

• Use SELECT to wait for I/O on existing sockets

CS423 - cotter 20

Apparent vs Real Concurrency

• Create a socket and bind to the well-known address for the service being offered. Add socket to the list of those on which I/O is possible

• Use select to wait for I/O on existing sockets• If original socket gets request, use accept for new

connection & add socket to the list• If other socket responds, use read / write to

communicate• Return to select

CS423 - cotter 21

Apparent Concurrency• Select (fdsize, &fd_set_in, &fd_set_out, &fd_set_err, time)

– Fdsize: Not used in Windows, but used in UNIX or Linux to indicate number of sockets that should be scanned.

– &fd_set_in: Address of the file descriptor set that is monitoring sockets for pending input work

– &fd_set_out: Address of the file descriptor set that is moniroting sockets for pending outgoing work.

– &fd_set_err: File descriptor set that monitors for exceptions to normal work (special error messages, or urgent messages)

– Time: set to NULL to wait until there is some activity. Otherwise may be set to the maximum time to wait until select function returns.

CS423 - cotter 22

Running Servers in Linux• For simple testing, run server in a separate terminal window as a

normal console process. – If server generates console output, that output is visible– Easy to see server response / failure

• For ongoing service, server should run as a background process, unattached to a console. – Detach process from console with “&”– # imServer 789 &– If owner locks screen, process continues– If owner logs off, process will terminate

• To terminate process without logging off:– Add terminate option to program (specific command / code, etc.– Determine process id (#ps aux) and terminate process (#kill –s 9

3456)

CS423 - cotter 23

Running Servers in Linux

• To keep process active after user logs off, start the process using “nohup” - - no hangup– May be run as local user (used to require root

privilege)– #nohup imServer 789 &– Any terminal output sent to a file “nohup.out”

• To terminate process:– Determine process ID (#ps aux | grep imServer ) =>

12073– Terminate process (#kill –s 9 12073)

CS423 - cotter 24

Example Linux Server

[cotterr@kc-sce-cs431c cs423]$ nohup ./imServer &[1] 5500[cotterr@kc-sce-cs431c cs423]$ nohup: ignoring input and appending output to ânohup.outâ

[cotterr@kc-sce-cs431c cs423]$ ps aux | grep imServercotterr 5500 71.3 0.0 2232 624 pts/0 R 09:26 0:11 ./imServercotterr 5502 0.0 0.0 109180 896 pts/0 S+ 09:27 0:00 grep --color=auto imServer[cotterr@kc-sce-cs431c cs423]$ kill -s 9 5500[cotterr@kc-sce-cs431c cs423]$

CS423 - cotter 25

Linux System Servers

• Generally known as Daemon Processes• Processes that are expected to have an extended life.• Run in the background (not associated with tty)• Generally started during system initialization– mail servers, web servers, ftp servers, echo servers, etc.

• syslog function:– Resource to store error and status messages for daemons,

etc. – Currently implemented using rsyslogd.– Configuration file /etc/rsyslog.conf

CS423 - cotter 26

Daemon Creation Process

• Call a fork, and close parent– puts process in the background– ensures that process isn’t process group leader.

• Create a new session – become a session /process group leader – ensure that there is no controlling terminal

• Change working directory to root– ensure that daemon isn’t running on a partition

that can be unmounted

CS423 - cotter 27

Daemon Creation Process

• Set file creation mask to 0– File creation mask controls how the daemon can

manipulate files. A mask of 0 ensures that any restrictions of the parent are removed for the daemon

• Close unneeded file descriptors

CS423 - cotter 28

Daemon init functioninclude <sys/types.h>,<sys/stat.h>,<fcntl.h>

int daemon_init(void) {

pid_t pid;

if ((pid = fork ( )) < 0)

return(-1);

else if (pid != 0) /* parent*/

exit (0);

setsid ( );

chdir(“/”);

umask(0);

return(0);

}

CS423 - cotter 29

Daemon Processes

• User Daemons– at command (for one time delayed processes)• at [-f file] time [date] [+increment] [command | file] ...• at -f myfile 6 am Friday• at now + 2 days uuclean

– crontab command (for repeating functions)• crontab -e (-r, -l)

– min hr day mon DOW command– 0 2 25 9 * myjob– 30 6 * * 1,3,5 /usr/bin/calendar

CS423 - cotter 30

Summary

• Several different factors involved in server design

• 4 basic types of servers

• Server concurrency can be real or apparent

• Linux server simple to run in background

CS423 - cotter 31