Design and Implementation of a Server Director

1. Design and Implementation of a Server Director Project for the LCCN Lab at the Technion

2. Submitted by: • Eyal Skulski, 032033862 • Pasha Glozman, 310073085 • Amir Idar, 028593606

3. Contents • Introduction • System Operation • Modules description and algorithms • Clients Module • Director Layer 5 Module • Director Layer 4 Module • NAT Module and Connection Table • Servers Module • Scheduler Module • Main Data Structures

4. 1. Introduction • Designers of internet servers which encounter large volumes of simultaneous TCP traffic (CNN.com for example), implement one of several designs for traffic management. • One possible solution is the introduction of a "Director" – a server which acts as an entry gate to several other servers holding the actual content. The Director's job is to accept each incoming http request ("Get") from the clients, to forward it to the chosen server, and to send back the reply to the requesting client. • The match of client to server is done in one of two primary ways – • In the first, the incoming message is not analyzed, but is delivered to a content server based on general considerations such as the server's current load. In the second, the data is analyzed, the client will be "connected" with the server holding the first requested page, and related topics. • The second method is generally preferable, as it uses a more knowledgeable decision base, however – analyzing each incoming request is a timely process, wasting a considerable amount of time and diminishing this method's efficiency. • The goal of our project is to test one possible solution to the inefficiency of testing each request – a Director which tests only the “get” request for each client, and then switches into a kind of "router", connecting this client to the server chosen by examination of the first request without further examination of packets from/to this client. We will implement such a Director on a Linux system, with web browsers as the clients, and two web servers as the proxies.

5. 7 Director Layer 5 6 3 13 15 23 8 14 SERVERS Connection Table NAT CLIENTS 11 2 10 17 20 5 4 9 21 18 1 12 Director Layer 4 Global 19 Local 22 16 Scheduler 2. System Operation Action: 23. Director Layer 5 removes rules from NAT, and entry from connection Table 10. Director Layer 4 updates entry with: Server Seq. #, Director-Server Seq. #, Director Port (server) 11-13. Completion of 3-way handshake between Director and selected server (schematic) 14. Director Layer 5 adds 2 rules to the NAT table – from server and from client 15. Director Layer 5 sends the GET request it has saved to the selected server 20. IP’s, Sequence numbers, and checksums are updated by the NAT mechanism 18. Server response and ACK reaches the client 19. Client ACK is sent to Director 21. Client ACK is sent to Server, (updated as Director ACK) 17. IP’s, Sequence numbers, and checksums are updated by the NAT mechanism 9. Director Layer 5 continues TCP connection to selected server via Layer 4 8. Director Layer 5 updates entry with: ServerIP, ServerPort(80) 7. Director Layer 5 calls Scheduler to select a server for the client’s GET request 6. GET request by client 3-5. Completion of 3-way Handshake between client and Director (Schematic) 2. Director Layer 4 adds initial entry to Connection Table • Client initiates TCP • connection with Director 22. Server FIN 16. Server sends response and ACK to the GET request

6. 3. Modules description and algorithms • Clients Module: No module for the clients is implemented within the project framework. Clients are web browsers running on one of the Lab computers. Each client initiates a TCP connection to port 80 as in a usual handshake, and requests http pages as if connecting to a regular server with the Director's IP address.

7. 3. Modules description and algorithms – cont. Director Layer 5 Module: • This module is implemented in Linux User Mode. • It is responsible for creating the initial TCP connection with clients, matching clients to their appropriate servers, based on the URL they request in the GET packet, creating the connection with the selected server, and adding/removing NAT rules in the rules table.

8. 3. Modules description and algorithms – cont. • Director Layer 5 Module Algorithm: • Wait for incoming TCP connections passed by Layer 4. • Upon receiving a new connection, create a thread to handle it, and process handshake until completed. • When receiving a GET request from a recognized client, pass the requested URL to the scheduler to choose the server for handling it, and save the request to enable sending it to the server shortly. • Update the Connections Table with the IP of the selected server, (port is always 80). • Create a TCP connection with the selected server, through Layer 4. • After Layer 4 updates the final details for the connection in the Connection Table, add bi- directional NAT rules. • Send the saved GET request which was received from the client to the server. * Comment: at this stage Layer 5 has finished its handling of the connection, since when the server sends the reply to the client, the rules are already updated in the NAT table, and from there on Layer 4 will automatically handle the communication. • Goto 1)

9. 3. Modules description and algorithms – cont. Director Layer 4 Module: • This module is implemented by alterations on the Linux kernel, within the framework of a module called IPVS, which we use as a NAT. • It is responsible for maintaining TCP connections and a TCP stack, for connections between clients/servers and Layer 5 until the NAT rules are set for each connection, at which stage it serves as a NAT "router", automatically updating packets so they are passed to/from clients/servers through the Director.

10. 3. Modules description and algorithms – cont. • Director Layer 4 Module Algorithm : • Wait for incoming TCP connections on Port 80. • Upon receiving a connection request – process request as usual, but add new client IP and port, client sequence number, and director to client sequence number to the Connections Table. (all IP packets are checked, and those coming to port 80 are filtered and checked whether they are TCP SYN packets, then TCP stack is simulated, creating real TCP connection etc., but we will not elaborate further, since these actions are made by the operating system). • Upon Director's initiation of a TCP connection with a selected server, update the Connection Table with server sequence number, Director to server sequence number, and Director (server) port. • For all packets destined for Director, call the NAT module to update their headers, if their source appears within a NAT rule. • Go to Step 1)

11. 3. Modules description and algorithms – cont. NAT Module and Connection Table: • This module is part of a module for the Linux system, which we adapted for our needs. • It is responsible for maintaining the Connection Table, used for matching client and server IPs, as well as "updating" necessary fields in TCP/IP packet headers (source/destination IPs, sequence numbers), and for maintaining the NAT rules.

12. 3. Modules description and algorithms – cont. Servers Module • This module is simulated by two web servers on Lab computers. • It is responsible for replying with appropriate http contents to GET requests from Director Layer 4 (on behalf of clients). • Comment: This module is implemented on the Lab computers, and we do not intend to change it.

13. 3. Modules description and algorithms – cont. Scheduler Module: • This module is in charge of selecting a server to handle the a given URL according to predetermined rules described by regular expressions, and passing the selected server IP back to Layer 5.

14. 4. Main Data Structures Connection Table: • This table supports efficient two-way connection between client IP's and ports to their selected server IP's and ports and vice-versa.

15. 4. Main Data Structures – cont. Server Content Table Used by the Scheduler module to determine which server to match with a client, based on the client's requested URL. • This table is defined statically within the Director class constructor.

16. 4. Main Data Structures – cont. NAT Rule Table Note: Detailed descriptions of the implementation in code of the modules, as well as technical notes – appear in the project’s Final Report file.