Server Design
Discuss Design issues for Servers
Review 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 Servers
Example
•
•
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 Servers
Example
•
•
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
hash(IP, port)
Filename: X
Offset: 512
Buffer Pointer:
Buffer for file X ,
pointer at 512
Buffer for file Y ,
pointer at 1024
Filename: Y
Offset: 1024
Buffer Pointer:
CS423 - cotter
7
Basic Server Types
CS423 - cotter
Iterative
connectionless
Iterative
connection-oriented
Concurrent
connectionless
Concurrent
connection-oriented
8
Basic Server Types
CS423 - cotter
Iterative
connectionless
Iterative
connection-oriented
Concurrent
connectionless
Concurrent
connection-oriented
9
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
Multiple low duty cycle clients can be handled by a
Single thread
CS423 - cotter
18
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 imServer
cotterr 5500 71.3 0.0 2232 624 pts/0 R 09:26 0:11
./imServer
cotterr 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 function
include <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