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) CS423 - cotter 2

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

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

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 CS423 - cotter 5

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

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

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

9. Basic Server Types CS423 - cotter 9 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. CS423 - cotter 10

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

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 CS423 - cotter 12

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 CS423 - cotter 13

14. Server Issues Request processing time Vs. Observed response time CS423 - cotter 14

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

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) CS423 - cotter 16

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 CS423 - cotter 17

18. Real vs. Apparent Concurrency CS423 - cotter18 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 CS423 - cotter 19

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 CS423 - cotter 20

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 CS423 - cotter 21

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

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) CS423 - cotter23

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) – #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 - cotter24

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 | 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 - cotter25

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 CS423 - cotter26

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 CS423 - cotter27

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 CS423 - cotter28

29. Daemon init function include,, int daemon_init(void) { pid_tpid; if ((pid = fork ( )) < 0) return(-1); else if (pid != 0)/* parent*/ exit (0); setsid ( ); chdir(“/”); umask(0); return(0); } CS423 - cotter29

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 CS423 - cotter30

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 CS423 - cotter 31