Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Server Software Design Prof. Chuan-Ming Liu Computer Science and Information Engineering National Taipei University of Technology Taipei, TAIWAN NTUT, TAIWAN 1
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Conceptual Server Algorithm Simple Server Algorithm 1. Create a socket 2. Bind the socket to the port 3. Enter an infinite loop Accept request Process request Reply request Not enough in practice generally NTUT, TAIWAN 2
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Conceptual Server Algorithm Consider file transfer First client needs a 200 MB file Second client needs a 20 byte file If the server processes them in FIFO fashion, the second client will wait an unreasonable amount of time for a small transfer Server usually handles more than one request at a time NTUT, TAIWAN 3
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Concurrent vs Iterative Iterative server : one request at a time Concurrent server : multiple requests at one time Note: the concurrency is conceptual and generally will use one thread for one request NTUT, TAIWAN 4
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Concurrent vs Iterative Concurrent server refers to whether the server permits multiple requests to proceed concurrently, not whether the underlying implementation uses multiple and concurrent threads NTUT, TAIWAN 5
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Concurrent vs Iterative Concurrent servers are difficult to design and build Why concurrency? Long delay caused by iterative servers Performance bottleneck resulted from iterative servers effects many clients NTUT, TAIWAN 6
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Connection Access or Not Two major transport protocols: TCP ( Transmission Control Protocol ) UDP ( User Datagram Protocol ) TCP is connection-oriented and UDP is connectionless The corresponding servers are Connection-oriented servers Connectionless serves NTUT, TAIWAN 7
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab TCP Semantics Point-to-point communication Reliable connection establishment Reliable delivery Flow controlled transfer Full-duplex transfer Stream paradigm NTUT, TAIWAN 8
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab UPD Semantics Many-to-many communication Unreliable Service Lack of flow control Message paradigm NTUT, TAIWAN 9
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab TCP or UDP? Because the semantics of TCP and UDP differ sharply, a designer cannot choose between connection-oriented and connectionless transport protocols without considering the semantics required by the application protocol Depends on the applications, not the types NTUT, TAIWAN 10
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Connection-Oriented Servers Easier to program since TCP provides all the reliability Drawbacks: Need a separate socket for each connection Care about the socket allocation and resource consuming Resource limitation problem – due to the clients can crash often NTUT, TAIWAN 11
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Connectionless Servers Access multiple hosts from a single socket No problem of resource depletion No reliable delivery Need to take care of the reliability Usually, clients take care of retransmitting request Server may retransmit as well NTUT, TAIWAN 12
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Connectionless Servers Achieving reliability can be difficult Timeout Retransmission TCP does not allow multicast or broadcast Multicast and broadcast services require UDP Any server that accepts or responds to multicast and broadcast communication must be connectionless NTUT, TAIWAN 13
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Stateful or Stateless The issue of stateless arises from a need to ensure reliability For a service using connectionless transport, like UDP, the application protocols need to ensure the reliability NTUT, TAIWAN 14
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Stateless Servers Consider a connectionless server that allows clients to read information from files Clients need to specify Filename Position in the file Amount to read Straightforward method is to handle each request independently NTUT, TAIWAN 15
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Optimizing Stateless Servers Observe that The overhead to open and close files is high Data read may be few Clients may sequentially read files Using buffers to assist reading files This may be similar to the stateful servers Hashing table is used The IP address and the port number form the index NTUT, TAIWAN 16
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Optimizing Stateless Servers Filename: X Offset: 512 Buffer for file X Buffer pointer: Starting at byte 512 Hash(ip, port) Filename: Y Buffer for file Y Offset 1024 Starting at byte 1024 Buffer pointer: NTUT, TAIWAN 17
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Optimizing Stateless Servers Improvement can be achieved when all the assumptions meet Problem arises when the client programs fail Consider the situation that the client crashes Buffer will be full Adjustment can be done by least recently used ( LRU ) rule for maintaining the hash table Thrashing occurs NTUT, TAIWAN 18
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Optimizing Stateless Servers A programmer must be extremely careful when optimizing a stateless server because managing small amounts of state information can consume resources if clients crash and reboot frequently or if the underlying network duplicates or delay messages NTUT, TAIWAN 19
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Types of Servers Iterative Iterative Connectionless Connection-oriented Concurrent Concurrent Connectionless Connection-oriented NTUT, TAIWAN 20
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Iterative or Concurrent Request processing time ( Server ) total time the server takes to handle a request Observed response time (Client) total delay from sending a request to receiving the response Server has a queue of requests to handle NTUT, TAIWAN 21
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Iterative or Concurrent If N is the average length of the request queue, then the observed response time is approximately ( N/2 +1) × the server’s request processing time The observed response time is in proportion to N, N should be reasonable small, say N =5 When N is small, an iterative server is ok; otherwise, a concurrent serve is preferred NTUT, TAIWAN 22
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Iterative or Concurrent Alternatively, the overall load can be considered Suppose a server is designed to handle K clients Each client sends R request per second Total number of requests is RK The server’s processing time should be less than 1/ KR second per request If the server can handle at the required rate, iterative way is ok; otherwise, concurrent method is selected NTUT, TAIWAN 23
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Iterative Server Algorithms Easy to design, program, debug, and modify. Working best with simple services accessed by a connectionless access protocol NTUT, TAIWAN 24
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Iterative Connection- Oriented Server Algorithm 1. Create a socket and bind to the well-known address for the service being offered 2. Place the socket in passive mode and make it ready for use by a server 3. Accept the next connection request from the socket, and obtain a new socket for the connection 4. Repeatedly read, process, and reply a request 5. When a particular connection is done, close the connection and go back to step 3 NTUT, TAIWAN 25
Mobile Computing & Software Engineering Lab Mobile Computing & Software Engineering Lab Binding a Well-known Address Like clients, servers use procedure getportbyname to map a service name into a well-known port number Using function bind to specify a connection IP address is necessary for bind , but it is difficult to select the IP address NTUT, TAIWAN 26
Recommend
More recommend
