Server Design

1. Server Design Discuss Design issues for Servers Review Server Creation in Linux

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)

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

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

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

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

7. Filename: X Offset: 512 Buffer Pointer: Filename: Y Offset: 1024 Buffer Pointer: Stateless Vs. Stateful Servers hash(IP, port) Buffer for file X , pointer at 512 Buffer for file Y , pointer at 1024

8. Basic Server Types Iterative connectionless Iterative connection-oriented Concurrent connectionless Concurrent connection-oriented

9. Basic Server Types Iterative connectionless Iterative connection-oriented Concurrent connectionless Concurrent connection-oriented

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

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

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

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

14. Server Issues • Request processing time Vs. Observed response time

15. Server Issues • Request processing time Vs. Observed response time • Use of INADDR_ANY to receive datagrams from any IP address.

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)

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

18. Real vs. Apparent Concurrency Multiple low duty cycle clients can be handled by a Single thread

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

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

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

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

23. 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)

24. 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) • #nohupimServer 789 & • Any terminal output sent to a file “nohup.out” • To terminate process: • Determine process ID (#ps aux | grepimServer) => 12073 • Terminate process (#kill –s 9 12073)

25. 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 | grepimServer cotterr5500 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]$

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

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

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

29. 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); }

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

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