myqueue;
75 |
76 | // 任务队列的最大大小
77 | int maxq;
78 |
79 | };
80 | }
81 | #endif
82 |
--------------------------------------------------------------------------------
/Lab1/src/Sudoku_answer.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/Sudoku_answer.png
--------------------------------------------------------------------------------
/Lab1/src/Sudoku_puzzle.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/Sudoku_puzzle.png
--------------------------------------------------------------------------------
/Lab1/src/Wrong_Example.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/Wrong_Example.png
--------------------------------------------------------------------------------
/Lab1/src/answer_group.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/answer_group.png
--------------------------------------------------------------------------------
/Lab1/src/test_group.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/test_group.png
--------------------------------------------------------------------------------
/Lab1/src/where_ext4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/where_ext4.png
--------------------------------------------------------------------------------
/Lab1/src/图2-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/图2-1.png
--------------------------------------------------------------------------------
/Lab1/src/图2-2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/图2-2.png
--------------------------------------------------------------------------------
/Lab1/src/图2-3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab1/src/图2-3.png
--------------------------------------------------------------------------------
/Lab2/README.md:
--------------------------------------------------------------------------------
1 | # Lab2: Your Own HTTP Server
2 |
3 | *Some materials are from Homework 2 of CS162 2019 at UC Berkeley.* *Thanks to CS162!*
4 |
5 | Enter in the folder you have cloned from our lab git repo, and pull the latest commit.
6 |
7 | `git pull`
8 |
9 | You can find this lab2's instruction in `Lab2/README.md`
10 |
11 | All materials of lab2 are in folder `Lab2/`
12 |
13 | ## 1. Overview
14 |
15 | Implement an HTTP server based on HTTP/1.1 from scratch by your own, using network programming knowledges learned from our class. Also, try to use high concurrency programming skills learned from the class to guarantee the web server's performance.
16 |
17 | ### Goals
18 |
19 | * Practice basic network programming skills, such as using socket API, parsing packets;
20 | * Get familiar with robust and high-performance concurrent programming.
21 |
22 | ## 2. Background
23 |
24 | ### 2.1 Hypertext Transport Protocol
25 |
26 | The Hypertext Transport Protocol (HTTP) is the most commonly used application protocol on the Internet today. Like many network protocols, HTTP uses a client-server model. An HTTP client opens a network connection to an HTTP server and sends an HTTP request message. Then, the server replies with an HTTP response message, which usually contains some resource (file, text, binary data) that was requested by the client. We briefly introduce the HTTP message format and structure in this section for your convenience. Detailed specification of HTTP/1.1 can be found in [RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1](https://tools.ietf.org/html/rfc2616).
27 |
28 | ### 2.2 HTTP Messages
29 |
30 | HTTP messages are simple, formatted blocks of data. All HTTP messages fall into two types: **request** messages and **response** messages. Request messages request an action from a web server. Response messages carry results of a request back to a client. Both request and response messages have the same basic message structure.
31 |
32 | #### 2.2.1 Message Format
33 |
34 | HTTP request and response messages consist of 3 components:
35 |
36 | - a start line describing the message,
37 | - a block of headers containing attributes,
38 | - and an optional body containing data.
39 |
40 | Each component has the format as following
41 |
42 | ##### 2.2.1.1 Start Line
43 |
44 | All HTTP messages begin with a start line. The start line for a request message says *what to do*. The start line for a response message says *what happened*.
45 |
46 | Specifically, the start line is also called ***Request line*** in *Request messages* and ***Response line*** in *Response messages*.
47 |
48 | 1. **Request line:** The request line contains a method describing what operation the server should perform and a request URL describing the resource on which to perform the method. The request line also includes an HTTP version tells the server what dialect of HTTP the client is speaking. All of these fields are separated by whitespace.
49 |
50 | Example of request line:
51 |
52 | `GET /index.html HTTP/1.1`
53 |
54 | 2. **Response line:** The response line contains the HTTP version that the response message is using, a numeric status code, and a textual reason phrase describing the status of the operation.
55 |
56 | Example of response line:
57 |
58 | `HTTP/1.1 200 OK`
59 |
60 | ##### 2.2.1.2 Header
61 |
62 | Following the start line comes a list of zero, one, or many HTTP header fields. HTTP header fields add additional information to request and response messages. They are basically just lists of name/value pairs. Each HTTP header has a simple syntax: a name, followed by a colon (:), followed by optional whitespace, followed by the field value, followed by a CRLF.
63 |
64 | HTTP headers are classified into: General headers, Request headers, Response headers, Entity headers and Extension headers. Note that request-header fields are different from the response-header fields. We will not introduce those fields in details and you are not required to implement in this lab. You can find them in [RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1](https://tools.ietf.org/html/rfc2616).
65 |
66 | Example of headers in a request:
67 |
68 | ```
69 | Host: 127.0.0.1:8888
70 | User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
71 | Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
72 | Accept-Language: en-US,en;q=0.5
73 | Accept-Encoding: gzip, deflate
74 | Connection: keep-alive
75 | Upgrade-Insecure-Requests: 1
76 | Cache-Control: max-age=0
77 | // CRLF
78 | ```
79 |
80 | Example of headers in a response:
81 |
82 | ```
83 | Server: Guo's Web Server
84 | Content-length: 248
85 | Content-type: text/html
86 | // CRLF
87 | ```
88 |
89 | ##### 2.2.1.3 Entity Body
90 |
91 | The third part of an HTTP message is the optional entity body. Entity bodies are the payload of HTTP messages. They are the things that HTTP was designed to transmit.
92 |
93 | HTTP messages can carry many kinds of digital data: images, video, HTML documents, software applications, credit card transactions, electronic mail, and so on.
94 |
95 | Example of entity body:
96 |
97 | ```
98 |
99 | CS06142
100 |
101 | CS06142
102 | Welcome to Cloud Computing Course.
103 |
104 |
105 | Http Server at ip-127-0-0-1 Port 8888
106 |
107 | ```
108 |
109 | #### 2.2.2 Structure of HTTP Request
110 |
111 | A HTTP request message contains an HTTP request line (containing a method, a query string, and the HTTP protocol version), zero or more HTTP header lines and a blank line (i.e. a CRLF).
112 |
113 | Example of HTTP request message:
114 |
115 | ```
116 | GET /index.html HTTP/1.1
117 | Host: 127.0.0.1:8888
118 | User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
119 | Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
120 | Accept-Language: en-US,en;q=0.5
121 | Accept-Encoding: gzip, deflate
122 | Connection: keep-alive
123 | Upgrade-Insecure-Requests: 1
124 | Cache-Control: max-age=0
125 | // CRLF
126 | ```
127 |
128 | #### 2.2.3 Structure of HTTP Response
129 |
130 | A HTTP response message contains an HTTP response status line (containing the HTTP protocol version, the status code, and a description of the status code), zero or more HTTP header lines, a blank line (i.e. a CRLF by itself) and the content requested by the HTTP request.
131 |
132 | Example of HTTP response message:
133 |
134 | ```
135 | HTTP/1.1 200 OK
136 | Server: Tiny Web Server
137 | Content-length: 248
138 | Content-type: text/html
139 | // CRLF
140 |
141 | CS06142
142 |
143 | CS06142
144 | Welcome to Cloud Computing Course.
145 |
146 |
147 | Http Server at ip-127-0-0-1 Port 8888
148 |
149 | ```
150 |
151 | ### 2.3 HTTP Proxy
152 |
153 | HTTP proxy servers are intermediaries. Proxies sit between clients and servers and act as "middlemen", shuffling HTTP messages back and forth between the parties.
154 |
155 | HTTP proxy servers are middlemen that fulfill transactions on the client's behalf. Without a HTTP proxy, HTTP clients talk directly to HTTP servers. With a HTTP proxy, the client instead talks to the proxy, which itself communicates with the server on the client's behalf.
156 |
157 | HTTP proxy servers are both web servers and web clients. Because HTTP clients send request messages to proxies, the proxy server must properly handle the requests and the connections and return responses, just like a web server. At the same time, the proxy itself sends requests to servers, so it must also behave like a correct HTTP client, sending requests and receiving responses.
158 |
159 | The working pattern of HTTP proxy is shown in the following figure:
160 |
161 | ```
162 | +-----------+ +-----------+
163 | | | | |
164 | +----------+ Request | | Request | |
165 | | |+---------------> |+--------------> |
166 | | Client | | Proxy | | Server |
167 | | <---------------+| <--------------+| |
168 | +----------+ Response | | Response | |
169 | | | | |
170 | +-----------+ +-----------+
171 | ```
172 |
173 | ## 3. Your Lab Task
174 |
175 | ### 3.1 Implement your own HTTP Server
176 |
177 | In this Lab, we won't provide any basic code. So, you should implement a HTTP server (base on HTTP/1.1) from scratch which satisfies the following requirements:
178 |
179 | #### 3.1.1 HTTP Server Outline
180 |
181 | From a network standpoint, your HTTP server should implement the following:
182 |
183 | 1. Create a listening socket and bind it to a port
184 | 2. Wait a client to connect to the port
185 | 3. Accept the client and obtain a new connection socket
186 | 4. Read in and parse the HTTP request
187 | 5. Start delivering services: 1) Handle HTTP GET/POST request and return an error message if an error occur. 2) Proxy the request to another HTTP server (optional for advanced version).
188 |
189 | The server will be in either non-proxy mode or proxy mode (we have introduced the proxy in section `2.3`). It does not do both things at the same time.
190 |
191 | #### 3.1.2 Handle HTTP request
192 |
193 | In this Lab, **you just need to implement the GET method and the POST method in your HTTP server**. That is to say, if your HTTP server receive a HTTP request but the request method is neither GET nor POST. The HTTP server just need to return a 501 Not Implemented error message (a response message with Response line having status code to be 501, see `2.2`).
194 |
195 | There is no need to handle the header line(s) in the request (but you need to recognize it so that you will not mix it with the next request's start line). Also, you are free to fill any (or zero) header line(s) in the HTTP response.
196 |
197 | ##### 3.1.2.1 Handle HTTP GET request
198 |
199 | The HTTP server should be able to handle HTTP GET requests for html pages.
200 |
201 | 1. If the HTTP request’s path corresponds to a html page file, respond with a 200 OK and the full contents of the file. For example, if GET /index.html is requested, and a file named index.html exists in the files directory. You should also be able to handle requests to files in subdirectories of the files directory (e.g. GET /images/hero.jpg).
202 | 2. If the HTTP request’s path corresponds to a directory and the directory contains an `index.html` file, respond with a 200 OK and the full contents of the index.html file in that folder.
203 | 3. If the requested page file does not exist, or the requested directory does not contain an `index.html` file, return a 404 Not Found response (the HTTP body is optional).
204 |
205 | See examples in section `3.1.7.1`.
206 |
207 |
208 | ##### 3.1.2.2 Handle HTTP POST request
209 |
210 | The HTTP server should be able to handle HTTP POST requests. In this lab, the way of handle HTTP POST is very simple.
211 |
212 | 1. You should construct an HTTP POST request (see section `3.1.7.2`) that contains 2 keys: "Name" and "ID" (please fill in your name and student number respectively), and send the POST request to `/Post_show` (i.e. `http://127.0.0.1:8888/Post_show` if server's IP is `127.0.0.1` and service port is `8888`).
213 |
214 | Then, if the HTTP server receive this POST request (the request URL is `/Post_show` and the keys are "Name" and "ID"), respond with a 200 OK and echo the "Name"-"ID" pairs you have sent.
215 |
216 | 2. Otherwise (i.e. the request URL is not `/Post_show` or the keys are not "Name" and "ID"), return a 404 Not Found response message.
217 |
218 | See examples in section `3.1.7.2`.
219 |
220 | ##### 3.1.2.3 Other request
221 |
222 | Just return 501 Not Implemented error message for other request method (e.g. DELETE, PUT, etc.).
223 |
224 | See examples in section `3.1.7.3`.
225 |
226 | #### 3.1.3 Implement a proxy server (optional)
227 |
228 | Enable your server to proxy HTTP requests to another HTTP server and forward the responses to the clients.
229 |
230 | 1. You should use the value of the `--proxy` command line argument, which contains the address and port number of the upstream HTTP server.
231 | 2. Your proxy server should wait for new data on both sockets (the HTTP client fd, and the upstream HTTP server fd). When data arrives, you should immediately read it to a buffer and then write it to the other socket. You are essentially maintaining 2-way communication between the HTTP client and the upstream HTTP server. Note that your proxy must support multiple requests/responses.
232 | 3. If either of the sockets closes, communication cannot continue, so you should close the other socket and exit the child process.
233 |
234 | Hints: 1) This is more tricky than writing to a file or reading from stdin, since you do not know which side of the 2-way stream will write data first, or whether they will write more data after receiving a response. 2) You should again use threads for this task. For example, consider using two threads to facilitate the two-way communication, one from A to B and the other from B to A.
235 |
236 | #### 3.1.4 Use multi-thread to increase concurrency
237 |
238 | Your HTTP server should use multiple threads to handle as many concurrent clients' requests as possible. You have at least the following three options to architect your multi-thread server:
239 |
240 | - **On-demand threads**. You can can create a new thread whenever a new client comes in, and use that thread to handle all that clients' task, including parsing the HTTP request, fetching page files, and sending response. The thread can be destroyed after that client finishes, e.g, detect through TCP `recv()`. However,it may not be easy to detect client finish in the HTTP layer.
241 | - **A pool of always-on threads**. You can use a fixed-sized thread pool in your HTTP server program for handling multiple client requests concurrently. If there are no tasks, those threads are in a waiting state. If a new client comes in, assign a thread to handle the client's request and send response to it. If the assigned thread is busy, you can use a work queue to buffer the request, and let the thread process it later.
242 | - **Combined**. Combine above two styles together. For example, you can use thread pool to receive request and send response, and use on-demand threads to fetch large page files.
243 |
244 | Feel free to choose any one from the above three, or use other multi-thread architecture that you think is cool.
245 |
246 | #### 3.1.5 Specify arguments
247 |
248 | Your program should enable long options to accept arguments and specify those arguments during start. They are `--ip`, `--port`, and `--proxy` (optional).
249 |
250 | 1. `--ip` —— Specify the server IP address.
251 | 2. `--port` —— Selects which port the HTTP server listens on for incoming connections.
252 | 4. `--proxy` —— Selects an “upstream” HTTP server to proxy. The argument can have a port number after a colon (e.g. `https://www.CS06142.com:80`). If a port number is not specified, port 80 is the default.
253 |
254 | If you have no idea about *long options*, you can read [this](https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html#Argument-Syntax). And you may need to use some functions like `getopt_long()`, `getopt_long_only()`, `getopt()` and so on. Check those function's usage with the `man` command.
255 |
256 | #### 3.1.6 Run your HTTP Server
257 |
258 | Your program should be able to start at terminal. If your program is called *httpserver*, just typing:
259 |
260 | in the non-proxy mode:
261 |
262 | `./httpserver --ip 127.0.0.1 --port 8888 --number-thread 8`
263 |
264 | It means that your HTTP server's IP address is 127.0.0.1 and service port is 8888. The --number-thread indicates that there are 8 threads in the thread pool for handling multiple client request concurrently.
265 |
266 | in the proxy mode:
267 |
268 | `./httpserver --ip 127.0.0.1 --port 8888 --number-thread 8 --proxy https://www.CS06142.com:80`
269 |
270 | It means that this is an HTTP proxy. This proxy's IP address is 127.0.0.1 and service port is 8888. And the proxy has a thread pool with 8 threads. The --proxy indicates that the "upstream" HTTP server is `https://www.CS06142.COM:80`. So, if you send a request message to this proxy (i.e. `127.0.0.1:8888`), it will forward this request message to the "upstream" HTTP server (i.e. `https://www.CS06142.com:80`) and forward the response message to the client.
271 |
272 | When you run the command above, your HTTP server should run correctly.
273 |
274 | #### 3.1.7 Accessing Your HTTP Server
275 |
276 | ##### 3.1.7.1 Using GET method
277 |
278 | 1. You can check that your HTTP server works by opening your web browser and going to the appropriate URL. [Note] IP 127.0.0.1 refers to the IP of local host. So you can use 127.0.0.1 to test your HTTP server on the same local machine.
279 |
280 | For example:
281 |
282 |
283 |
284 | You can also send HTTP requests with the curl program. An example of how to use curl is:
285 |
286 | `curl -i -X GET http://127.0.0.1:8888/index.html`
287 |
288 | For example:
289 |
290 |
291 |
292 | 2. If the request page does not exist, your HTTP server should return a 404 Not Found error message.
293 |
294 | For example:
295 |
296 |
297 |
298 | ##### 3.1.7.2 Using POST method
299 |
300 | 1. You can check whether the POST method works by sending a HTTP request with the curl program. Typing the command at terminal:
301 |
302 | `curl -i -X POST --data 'Name=HNU&ID=CS06142' http://127.0.0.1:8888/Post_show`
303 |
304 | For example:
305 |
306 |
307 |
308 | You can also construct a POST HTTP request and send the request to HTTP server using some browser plug-in tools.
309 |
310 | 2. If the request URL is not `/Post_show` or the keys are not "Name" and "ID"), you will get a 404 Not Found error message.
311 |
312 | For example:
313 |
314 |
315 |
316 | ##### 3.1.7.3 Other method
317 |
318 | The HTTP server will not handle HTTP requests except GET requests and POST requests.
319 |
320 | If you send a HTTP DELETE (or PUT, HEAD, etc.) request to delete the specified resource, you will get a 501 Not Implemented error message:
321 |
322 |
323 |
324 | #### 3.1.8 Implementation requirements
325 |
326 | ##### 3.1.8.1 Basic version
327 |
328 | Your program should complete all the **tasks described in section `3.1.1~3.1.7` except `3.1.3`**.
329 |
330 | In the basic version, you have **only one request per TCP connection going on at the same time**. The client waits for response, and when it gets response, perhaps reuses the TCP connection for a new request (or use a new TCP connection). This is also what normal HTTP server supports.
331 |
332 | ##### 3.1.8.2 Advanced version
333 |
334 | Your program should complete all the **tasks described in section `3.1.1~3.1.7` including`3.1.3`**.
335 |
336 | In the advanced version, **multiple http requests can be fired concurrently on one TCP connection**. This is also called HTTP pipelining which is supported by many real browsers and servers (such as Chrome). Note that HTTP requests that come from the same TCP connection should be responded in the same order. So take care the order problem when using complex multi-thread styles.
337 |
338 | ### 3.2 Finish a performance test report
339 | Please test your code first, and commit a test report along with your lab code into your group’s course github repo.
340 |
341 | The test report should describe the performance result under various testing conditions. Specifically, in your test report, you should at least contain the following two things:
342 |
343 | 1. Test how many HTTP request your server can process per second, when running on various server machine environments. For example, change the number of server CPU cores, enable/disable hyper-threading, etc.
344 | 2. Test how many HTTP request your server can process per second, by varying the number of concurrent clients that send request to your server simultaneously. Do change the client's workload. For example, test when a client use new TCP connection for a new request, or when a client reuses old TCP connection for new requests. Moreover, if you implement the advanced version, try to change the number of out-bounding requests on the same client's TCP connection. You can write a simple client that send HTTP Get by your own (can run multiple client programs on the same machine to emulate multiple clients), or use some existing HTTP client testing tools such as [ab - Apache HTTP server benchmarking tool](http://httpd.apache.org/docs/current/programs/ab.html).
345 |
346 | **[NOTE]**: Be careful that clients may be the performance bottleneck. So you'd better use multiple machines when testing the performance. For example, you can run multiple client processes on three machines (of three group members), and run the server process on another machine (of the other group member). Moreover, the network can be the bottleneck too. You can estimate the performance limit according to the physical bandwidth of your network environment, and see if your implementation can reach the performance limit.
347 |
348 |
349 | ## 4. Lab submission
350 |
351 | Please put all your code in folder `Lab2` and write a `Makefile` so that we **can compile your code in one single command** `make`. The compiled runnable executable binary should be named `httpserver` and located in folder `Lab2`. Please carefully following above rules so that TAs can automatically test your code!!!
352 |
353 | Please submit your lab program and performance test report following the guidance in the [Overall Lab Instructions](../README.md) (`../README.md`)
354 |
355 | ## 5. Grading standards
356 |
357 | 1. You can get 23 points if you can: 1) finish all the requirements of the basic version, and 2) your performance test report has finished the two requirements described before. If you missed some parts, you will get part of the points depending how much you finished.
358 | 2. You can get 25 points (full score) if you can: 1) finish all the requirements of the advanced version, and 2) your performance test report has finished the two requirements described before. If you missed some parts, you will get part of the points depending how much you finished.
--------------------------------------------------------------------------------
/Lab2/src/get_404_curl.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/get_404_curl.png
--------------------------------------------------------------------------------
/Lab2/src/index.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/index.png
--------------------------------------------------------------------------------
/Lab2/src/index_curl.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/index_curl.png
--------------------------------------------------------------------------------
/Lab2/src/not_implemented.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/not_implemented.png
--------------------------------------------------------------------------------
/Lab2/src/not_implemented_curl.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/not_implemented_curl.png
--------------------------------------------------------------------------------
/Lab2/src/post_404_curl.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/post_404_curl.png
--------------------------------------------------------------------------------
/Lab2/src/post_curl.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab2/src/post_curl.png
--------------------------------------------------------------------------------
/Lab3/README.md:
--------------------------------------------------------------------------------
1 | # Lab 3: A Simple Distributed Key-Value Store
2 |
3 | Enter in the folder you have cloned from our lab git repo, and pull the latest commit.
4 |
5 | `git pull`
6 |
7 | You can find this lab3's instruction in `Lab3/README.md`
8 |
9 | All materials of lab3 are in folder `Lab3/`
10 |
11 | ## 1. Overview
12 |
13 | Implement a simple distributed in-memory key-value database (KV store) by your own, using two-phase commit protocol to guarantee the consistency and robustness of your KV store.
14 |
15 | ### Goals
16 |
17 | * Get to know the problems and difficulties in building a distributed system;
18 | * Know how to use a simple protocol to maintain consistency between multiple distributed servers;
19 | * Use some simple schemes to handle server failures.
20 |
21 | ## 2. Background
22 |
23 | ### 2.1 KV store
24 |
25 | An in-memory key-value database (also called **key-value store**, or **KV store** in this document) is a database that keeps all its data in the main memory and uses a simple key-value data structure.
26 |
27 | Typically, a KV-store exposes the following methods for users to store/delete/read data to/from the databases:
28 |
29 | - **set(key, value)**: stores the value "value" with the key "key" (some KV stores also call this command as "**put**").
30 | - **del(key)**: deletes any record associated with the key "key".
31 | - **value=get(key)**: retrieves and returns the value associated with the key "key".
32 |
33 | In practice, in-memory KV store serves most user requests only with data stored in the main memory, meanwhile, it often backups its data in the hard disks thus to be durable. However, in this lab, you are not required to consider the data durability (i.e., you can only store the data in main memory).
34 |
35 | ### 2.2 Distributed KV store
36 |
37 | In large-scale cloud services, KV stores are often built in distributed manner, for the sake of **performance and robustness**.
38 |
39 | For example, a KV store may distribute its data in multiple server machines, and simultaneously use those servers to serve user requests. As such, user requests can be evenly balanced to multiple servers when the load is high, and the database can survive from the failure of some servers.
40 |
41 | However, when the KV database is distributed, many problems arise. Among those problems, **consistency issue** may be most notorious and toughest one. For example, assume that a KV database uses two servers A and B to hold data and serve user requests. When user 1 put some key at server A, and then after a very short time user 2 and 3 each posts a get request of this key to server A and B, respectively, then how to make sure that user 2 and 3 both **get the same latest value of this key**? What is more challenging, failures can happen on servers and networks when users are posting requests.
42 |
43 | Next, we will introduce a very simple but classic protocol to ensure consistency among distributed database servers.
44 |
45 | ### 2.3 Two-phase commit
46 |
47 | Now we describe possibly the simplest (but it works!) consensus protocol called **two-phase commit**, or **2PC**. This protocol can ensure the data consistency when the database is located on multiple distributed servers, that is, **two or more machines agree to do something, or not do it, atomically**. Note that this is only a very short introduction. You are encouraged to search more materials if you have further questions (e.g., [this](https://www.bilibili.com/video/BV1at411y7iQ) is a good video about 2PC).
48 |
49 | Frist, 2PC maintains a **commit log** on each machine, which keeps track of whether commit has happened. Log is used to guarantee that all machines either commit or don’t.
50 |
51 | Second, there is **one global coordinator**. It receives transactions from clients (e.g., set/delete/get) and reply results to clients, and coordinates multiple database servers, to ensure either all servers commit the transaction or all abort it.
52 |
53 | Based on above architecture, 2PC operates in two distinct phases:
54 |
55 | 1) The first phase is **prepared phase**. The global coordinator requests that all database servers (called participants) will promise to commit or rollback the transaction (e.g., set or delete a key) . Participants record promise in log, then acknowledge. If anyone votes to abort, coordinator writes "Abort" in its log and tells everyone to abort; each records "Abort" in log.
56 |
57 | 2) The second phase is **commit-or-abort phase**. After all participants respond that they are prepared, then the coordinator writes "Commit" to its log. Then the coordinator asks all participants to commit; All participants respond with ACK. After receive ACKs, the coordinator writes "Got Commit" to log.
58 |
59 |
60 |
61 | The detailed steps in 2PC are as follows:
62 |
63 | ***Prepared phase:***
64 |
65 | 1) To commit the transaction, the coordinator starts by sending a **REQUEST-TO-PREPARE** message to each
66 | participant.
67 |
68 | 2) The coordinator waits for all participants to "vote" on the request.
69 |
70 | 3) In response to receiving a **REQUEST-TO-PREPARE** message, each participant votes by sending a message back to the coordinator, as follows:
71 |
72 | - It votes **PREPARED** if it is prepared to commit.
73 | - It may vote **NO** for any reason, usually because it cannot prepare the transaction due to a local failure.
74 | - It may delay voting indefinitely, for example, because the network drops the vote.
75 |
76 | ***Commit-Or-Abort phase:***
77 |
78 | 1) If the coordinator receives **PREPARED** messages from all participants, it decides to commit. The transaction is now officially committed. Otherwise, it either received a **NO** message or gave up waiting for some participant, so it decides to abort.
79 |
80 | 2) The coordinator sends its decision to all participants (i.e.,**COMMIT** or **ABORT**).
81 |
82 | 3) Participants acknowledge receipt of the commit or abort by replying **DONE**.
83 |
84 | 4) After receiving **DONE** from all participants, the coordinator can reply clients with the transaction result (either success or failed), and *forget* the transaction, meaning that it can deallocate any memory it was using to keep track of information about the transaction.
85 |
86 | ## 3. Your Lab Task
87 |
88 | ### 3.1 Task overview
89 |
90 |
91 |
92 | You need to implement a simple distributed KV store. Your KV store should run as a network service on remote machine(s), which can receive clients' operations on the database and return results to clients, through network messages. To cope with failures, your are required to implement your KV store services on multiple machines (which are connected with each other through network). Use 2PC protocol to maintain database consistency among multiple machines.
93 |
94 | To simplify the task, your KV store data is only stored in main memory. Also, the log in 2PC protocol is also only stored in main memory.
95 |
96 | Detailed lab requirements are discussed below.
97 |
98 | ### 3.2 KV store command formats
99 |
100 | Your KV store servers are only required to support three database commands: `SET`, `GET` and `DEL` commands (case sensitive). These commands (including arguments) and the return results are encapsulated into network messages using dedicated message format. For simplicity, all the keys and values are stored as strings in your KV store.
101 |
102 | Further details are as follows:
103 |
104 | #### 3.2.1 Network message format
105 |
106 | In this lab, you should use a **simplified version** of RESP (REdis Serialization Protocol) message format to pass KV store commands from clients to servers (called request message) and pass command results from server to clients (called response message) . Specifically:
107 |
108 | ##### 3.2.1.1 Client request message
109 |
110 | Clients send commands to the server using RESP Arrays (more details see `section 3.2.2`). RESP Arrays consist of:
111 |
112 | - A `*` character as the first byte, followed by the number of elements in the array as a decimal number, followed by CRLF.
113 | - Arbitrary number of bulk strings (up to 512 MB in length).
114 |
115 | The bulk string consist of:
116 |
117 | - A `$` byte followed by the number of bytes composing the string (a prefixed length), terminated by CRLF.
118 | - The actual string data.
119 | - A final CRLF.
120 |
121 | For example, the string `CS06142` is encoded as follows:
122 |
123 | `$7\r\nCS06142\r\n`
124 |
125 | The bulk string `$7\r\nCS06142\r\n` start with a `$` byte, and the following number 7 indicate that the length of string `CS06142` is 7. Then, the terminated CRLF, actual string data `CS06142` and the final CRLF are next, consecutively.
126 |
127 | ##### 3.2.1.2 Server response message
128 |
129 | 1) Success message:
130 |
131 | Success messages are encoded in the following way: a plus '+' character, followed by a string that cannot contain a CR or LF character (no newlines are allowed), terminated by CRLF (that is "\r\n").
132 |
133 | For example, the `SET` command reply with just "OK" on success (more details see `section 3.2.2`):
134 |
135 | `+OK\r\n`
136 |
137 | 2) Error message:
138 |
139 | Like success messages, error messages consist of: a minus '-' character, followed by a string, terminated by CRLF.
140 |
141 | For example, if an error occurs, just return (more details see `section 3.2.2`):
142 |
143 | `-ERROR\r\n`
144 |
145 | 3) RESP Arrays message:
146 |
147 | Your server should return an RESP Arrays message when the `GET` command executed successfully (more detail see `section 3.2.2`).
148 |
149 | For example:
150 |
151 | `*2\r\n$5\r\nCloud\r\n$9\r\nComputing\r\n`
152 |
153 | 4) Integer message:
154 |
155 | Some commands need to return an integer (e.g., `DEL` command, more details see `section 3.2.2`). An integer message is just a CRLF terminated string representing an integer, prefixed by a ":" byte.
156 |
157 | An integer message example:
158 |
159 | `:1\r\n`
160 |
161 | #### 3.2.2 Database commands
162 |
163 | ##### 3.2.2.1 SET command
164 |
165 | `SET key value`
166 |
167 | The function of the `SET` command is to set **key** to hold the string **value**. If key already holds a value, it is overwritten. For example, if you want to set key `CS06142` to hold the string `Cloud Computing`, the command would be:
168 |
169 | `SET CS06142 "Cloud Computing"`
170 |
171 | According to the message format we have discussed in `section 3.2.1`, this command would be encoded as a RESP message format:
172 |
173 | `*4\r\n$3\r\nSET\r\n$7\r\nCS06142\r\n$5\r\nCloud\r\n$9\r\nComputing\r\n`
174 |
175 | **Note:** The encoded message start with a `*` byte. The following number 4 indicate that there are 4 bulk strings in this message. These bulk strings are `$3\r\nSET\r\n`, `$7\r\nCS06142\r\n`, `$5\r\nCloud\r\n`, and `$9\r\nComputing\r\n`.
176 |
177 |
178 | If the `SET` operation succeeds, the server will return a success message; otherwise, return an error message.
179 |
180 | For example, if the `SET` operation succeeds, the server just returns:
181 |
182 | `+OK\r\n`
183 |
184 | Otherwise, it returns:
185 |
186 | `-ERROR\r\n`
187 |
188 | ##### 3.2.2.2 GET command
189 |
190 | `GET key`
191 |
192 | `GET` command can get the **value** of **key**. If the key does not exist the special value `nil` is returned.
193 |
194 | For example, if you want to check the value of the key `CS06142`, construct the command like this:
195 |
196 | `GET CS06142`
197 |
198 | Like the `GET` command, this command should be encoded as a specific message format before sending to the server.
199 |
200 | `*2\r\n$3\r\nGET\r\n$7\r\nCS06142\r\n`
201 |
202 | If the `GET` command was executed correctly, the value (encoded as RESP Arrays format) of the key will be returned.
203 |
204 | For example, if the command above executed correctly, return:
205 |
206 | `*2\r\n$5\r\nCloud\r\n$9\r\nComputing\r\n`
207 |
208 | , assuming the value of the key `CS06142` is`Cloud Computing`.
209 |
210 | If the key does no exist, just return:
211 |
212 | `*1\r\n$3\r\nnil\r\n`
213 |
214 | If an error occurs, return an error message:
215 |
216 | `-ERROR\r\n`
217 |
218 | ##### 3.2.2.3 DEL command
219 |
220 | `DEL key1 key2 ...`
221 |
222 | The `DEL` command is used for removing one or more specified **keys** (arbitrary number, up to 512 MB message length). A key is ignored if it does not exist.
223 |
224 | The `DEL` command should return the number of keys that were removed.
225 |
226 | For example, if you want to delete key `CS06142` and key `CS162`, you can construct the `DEL` command:
227 |
228 | `DEL CS06142 CS162`
229 |
230 | Similar to the `SET` and `GET` commands, the `DEL` command will be encoded in RESP message as follows:
231 |
232 | `*3\r\n$3\r\nDEL\r\n$7\r\nCS06142\r\n$5\r\nCS162\r\n`
233 |
234 | The server will return the number of keys that were removed.
235 |
236 | For example, if the `DEL` command above executed, return an integer message:
237 |
238 | `:1\r\n`
239 |
240 | **note:** Because we only set the key `CS06142` to hold a value. As for key `CS162`, it will be ignored because it does no exist. So, the number in the integer message is 1.
241 |
242 | If an error occurs, return an error message:
243 |
244 | `-ERROR\r\n`
245 |
246 | ### 3.3 Use 2PC protocol to build a KV store on multiple servers
247 |
248 | You should implement the coordinator and participant program.
249 |
250 | The **coordinator** does not store any data. It only receives and parses KV commands from clients, runs 2PC protocol to coordinates participants to conduct the KV commands consistently, and reply command results to clients. *There is only one coordinator in the whole system*.
251 |
252 | Each **participant** maintains a KV database in its main memory, and conduct KV commands sent from the coordinator, and return results to the coordinator.
253 |
254 | You can use any message format for communication between the coordinator and participants. For example, you can also use the RESP format introduced before, or use some other RPC library.
255 |
256 | ### 3.4 Run your program
257 |
258 | #### 3.4.1 Program arguments
259 |
260 | Enable long options to accept arguments in your program, just like lab2. There should be one and only one argument for your program: `--config_path`, which specifies the path of the configuration file. All the detailed configurations are written in the configuration file. Your program should read and parse the configuration file, and run as coordinator or participant accordingly.
261 |
262 | If your program is called **kvstore2pcsystem**:
263 |
264 | run the **coordinator** process, just typing (`./src/coordinator.conf` is the coordinator's configuration file)
265 |
266 | `./kvstore2pcsystem --config_path ./src/coordinator.conf`
267 |
268 | run the **participant** process, just typing (`./src/participant.conf` is the participant's configuration file)
269 |
270 | `./kvstore2pcsystem --config_path ./src/participant.conf`
271 |
272 | When you run the command above, your program should run correctly without any further inputs.
273 |
274 | #### 3.4.2 Configuration file format
275 |
276 | A configuration file consists of two kinds of lines: 1) parameter line, and 2) comment line.
277 |
278 | - **A comment line** starts with a character '!'. The whole comment line are not parsed by the program.
279 | - **A parameter line** starts with a *parameter*, followed by a *value*. The parameter and value are separated by a whitespace. Parameter lines specify the necessary information that the coordinator or participants should know before running. There are three valid parameters: `mode`, `coordinator_info`, and `participant_info`.
280 | - The parameter `mode` specifies that whether the program runs as a coordinator or a participant. Its value should only be either `coordinator` or `participant`. `mode` line is always *the first parameter line* in the configuration file.
281 | - The parameter `coordinator_info` specifies the network address that the coordinator is listening on. Its value consists of the IP address and port number (separated by character ':'). Clients and participants can communicate with the coordinator using this network address. Since there is only one coordinator, there is only one `coordinator_info` line in both coordinator's and participants' configuration file.
282 | - The parameter `participant_info` consists of the network address that participant process is listening on. Its value consists of the IP address and port number (separated by character ':'). The coordinator can communicate with the participant using this network address. For participants, there is only one `participant_info` line in the configuration file, specifying its own network address; For the coordinator, there can be multiple `participant_info` lines in the configuration file, specifying the network addresses of all participants.
283 |
284 | Sample coordinator configuration file:
285 |
286 | ```
287 | !
288 | ! Coordinator configuration
289 | ! 2020/05/07 11:25:33
290 | !
291 | ! The argument name and value are separated by whitespace in the configuration file.
292 | !
293 | ! Mode of process, coordinator OR participant
294 | mode coordinator
295 | !
296 | ! The address and port the coordinator process is listening on.
297 | ! Note that the address and port are separated by character ':'.
298 | coordinator_info 127.0.0.1:8001
299 | !
300 | ! Address and port information of all participants.
301 | ! Three lines specifies three participants' addresses.
302 | participant_info 127.0.0.1:8002
303 | participant_info 127.0.0.1:8003
304 | participant_info 127.0.0.1:8004
305 | ```
306 |
307 | Sample participant configuration file:
308 |
309 | ```
310 | !
311 | ! Participant configuration
312 | ! 2020/05/07 11:25:33
313 | !
314 | ! The argument name and value are separated by whitespace in the configuration file.
315 | !
316 | ! Mode of process, coordinator OR participant
317 | mode participant
318 | !
319 | ! The address and port the participant process is listening on.
320 | participant_info 127.0.0.1:8002
321 | !
322 | ! The address and port the coordinator process is listening on.
323 | coordinator_info 127.0.0.1:8001
324 | ```
325 |
326 | ### 3.5 Implementation requirements
327 |
328 | #### 3.5.1 Basic version
329 |
330 | Your program should complete all the tasks described in `section 3.1-3.4`. Your system is required to correctly receive and conduct the KV commands, and reply the corresponding results, as described before.
331 |
332 | In the basic version, there will be **no participant failures**. Also, we will **not inject any network failures**. However, the network may still drop packets occasionally. You can use TCP to handle such occasional drops.
333 |
334 | **The coordinator process may be killed and restart at any time for multiple times**. So do not store any database data in the coordinator. The coordinator will deal with clients' KV commands when it is working. When the coordinator is killed, your system is not required to reply any client's commands. Clients will keep retransmit its KV commands until it gets success response from the coordinator. The coordinator remembers no history (except for the information in the configuration file), so it will deal with all commands as new ones after it restarts.
335 |
336 | Your program should run correctly with 3 or more participants.
337 |
338 | #### 3.5.2 Advanced version
339 |
340 | Your program should complete all the tasks described in `section 3.1-3.4`. Your system is required to correctly receive and conduct the KV commands, and reply the corresponding results, as described before.
341 |
342 | In the advanced version, **participants may fail, and the network links may fail**. However, the participant and network link **failures are one-shot**, that is, if they fail, they will never come back again. Also, **the coordinator process may be killed and restart at any time for multiple times**. The coordinator will deal with clients' KV commands when it is working. When the coordinator is killed, your system is not required to reply any client's commands.
343 |
344 | When the coordinator is working, it should be able to detect the failure of participants. You can use some periodical heartbeat messages to detect the participant failure (e.g., no reply after certain number of heartbeats). **Once a participant is dead, the coordinator should be able to remove it from the system, and correctly receive/conduct/reply clients' KV commands with the rest participants**. If all participants fail, the coordinator will always reply ERROR to the clients' KV commands. The coordinator remembers no history (except for the information in the configuration file), so it need to redetect all the participants' liveness after restart.
345 |
346 | Your program should run correctly with 3 or more participants.
347 |
348 | **NOTE**: **Groups that have registered for demo 3 should at least finish the advanced version.**
349 |
350 | #### **3.5.3 Extreme version**
351 |
352 | Your program should complete all the tasks described in `section 3.1-3.4`. Your system is required to correctly receive and conduct the KV commands, and reply the corresponding results, as described before.
353 |
354 | In the extreme version, **participants may fail, and the network links may fail**. The participant and network link **failures can be both permanent or transient**, that is, if they fail, they may come back again at any time. Also, **the coordinator process may be killed and restart at any time for multiple times**. The coordinator will deal with clients' KV commands when it is working. When the coordinator is killed, your system is not required to reply any client's commands.
355 |
356 | When the coordinator is working, it should be able to detect **both failure and recovery** of participants. Once a participant is dead, the coordinator should be able to remove it from the system; Once a participant is recovered, the coordinator should be able to add it back to the system. Note that to keep database consistent, after a participant recovers from failure, you should copy the latest KV store database from some working participants to this recovered participant. We will not provide any copy protocols for you. You are encouraged to devise your own schemes as long as it is correct. You should be very careful about the consistency issue since the failures can be very complex and random. For example, considering the case that there are two participants A and B, A fails first and then A comes back and B fails later. During this procedure, client's may keep sending KV commands, so A needs to sync those new KV commands after coming back, otherwise it cannot server client's request correctly after B fails.
357 |
358 | We will randomly inject failure and recovery to all the participants and network links. To ensure the database can be successfully copied, during our test, after a participant (or its network link) is recovered from failure, we will ensure that *no failures happen in the following 10 seconds* (no coordinator/participant/network failure). Your coordinator should be able to copy the latest database to the newly recovered participant in this 10 seconds. Moreover, we will always ensure that *there is at least one working participant* in the system. As such, the coordinator should be able to correctly receive/conduct/reply clients' KV commands during the failures and recoveries.
359 |
360 | Your program should run correctly with 3 or more participants.
361 |
362 | **NOTE**: **Groups that have registered for demo 4 should at least finish the extreme version.**
363 |
364 | #### **3.5.6 Ultimate version**
365 |
366 | Since the coordinator may permanently fail, your system should also **be able to deal with clients' requests even when coordinator fails**. 2PC is not able to handle this problem. So in this version, you will not use 2PC protocol, but use some advanced consensus protocol to handle this case.
367 |
368 | You can implement multiple KV store servers, where each server can receive requests from clients, stores data, and reply responses. Clients are preconfigured with all servers' addresses, and may send KV commands to any of the server, randomly. To keep consistency, normally there is only one leader server that deal with all the clients' requests, and backup the data in other servers. Clients' commands to other servers are all redirected to the leader. The consensus protocol can help servers to detect the failure of the leader server, and reelect a new leader. Also, the consensus protocol can help to maintain database consistency among multiple servers.
369 |
370 | [Raft](https://raft.github.io/) is a very good consensus protocol for this purpose. You may want to read its paper by yourself and use raft to implement this version (there are many open-sourced raft implementation that you can borrow). Sorry I'm not going to teach you this :) Of course, it is always good to use other consensus protocols or even your own schemes.
371 |
372 | **NOTE**: **This version is very difficult, so it is not compulsory but just a challenge. Have fun!**
373 |
374 | ## 4. Lab submission
375 |
376 | Please put all your code in folder `Lab3` and write a `Makefile` so that we **can compile your code in one single command** `make`. The compiled runnable executable binary should be named `kvstore2pcsystem` and located in folder `Lab3`. Please carefully following above rules so that TAs can automatically test your code!!!
377 |
378 | You can use any available code or library for this lab. Please search the Internet. However, do not copy other teams' code. No performance test report is required for this lab. Enjoy the lab :)
379 |
380 | Please submit your lab program following the guidance in the [Overall Lab Instructions](../README.md) (`../README.md`)
381 |
382 | ## 5. Grading standards
383 |
384 | 1. You can get 13 points if you can finish all the requirements of the basic version. If you missed some parts, you will get part of the points depending how much you finished.
385 | 2. You can get 21 points if you can finish all the requirements of the advanced version. If you missed some parts, you will get part of the points depending how much you finished.
386 | 3. You can get 24 points if you can finish all the requirements of the extreme version. If you missed some parts, you will get part of the points depending how much you finished.
387 | 4. You can get 25 points if you can finish all the requirements of the ultimate version. If you missed some parts, you will get part of the points depending how much you finished.
--------------------------------------------------------------------------------
/Lab3/src/KVStoreOverview.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab3/src/KVStoreOverview.jpg
--------------------------------------------------------------------------------
/Lab3/src/KVStoreOverview.pptx:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab3/src/KVStoreOverview.pptx
--------------------------------------------------------------------------------
/Lab3/src/coordinator_sample.conf:
--------------------------------------------------------------------------------
1 | !
2 | ! Coordinator configuration
3 | ! 2020/05/07 11:25:33
4 | !
5 | ! The argument name and value are separated by whitespace in the configuration file.
6 | !
7 | ! Mode of process, coordinator OR participant
8 | mode coordinator
9 | !
10 | ! The address and port the coordinator process is listening on.
11 | ! Note that the address and port are separated by character ':'.
12 | coordinator_info 127.0.0.1:8001
13 | !
14 | ! Address and port information of all participants.
15 | ! Three lines specifies three participants' addresses.
16 | participant_info 127.0.0.1:8002
17 | participant_info 127.0.0.1:8003
18 | participant_info 127.0.0.1:8004
--------------------------------------------------------------------------------
/Lab3/src/participant_sample.conf:
--------------------------------------------------------------------------------
1 | !
2 | ! Participant configuration
3 | ! 2020/05/07 11:25:33
4 | !
5 | ! The argument name and value are separated by whitespace in the configuration file.
6 | !
7 | ! Mode of process, coordinator OR participant
8 | mode participant
9 | !
10 | ! The address and port the participant process is listening on.
11 | participant_info 127.0.0.1:8002
12 | !
13 | ! The address and port the coordinator process is listening on.
14 | coordinator_info 127.0.0.1:8001
--------------------------------------------------------------------------------
/Lab3/src/two-phase-commit.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/lxthnu/CloudComputingLabs/74dcd2c1e4dd5d97615173a6aaedc7927bac9c07/Lab3/src/two-phase-commit.png
--------------------------------------------------------------------------------
/Lab4/README.md:
--------------------------------------------------------------------------------
1 | # Lab 4: A "Serious" Web-Retail System
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Cloud Computing: Overall Lab Instruction
2 |
3 |
4 |
5 | ## 1. Overview
6 |
7 | There are **4 labs in total** in this course. All the materials of each lab are under folders Lab1-4 in this repo. Please clone the lab git repo onto your local computer,
8 |
9 | `git clone https://github.com/1989chenguo/CloudComputingLabs.git`
10 |
11 | and always track our latest lab materials using the following commands (should first enter the folder you have cloned from our lab repo)
12 |
13 | `git pull`
14 |
15 | You can find this overall lab instruction in `README.md` in the root folder.
16 |
17 | Please **carefully read the overall lab instruction before you do anything**.
18 |
19 | Also, please **carefully read each lab's instruction** ([Lab1](Lab1/README.md), [Lab2](Lab2/README.md), [Lab3](Lab3/README.md), [Lab4](Lab4/README.md)) to get each lab's task, background, requirements, etc.
20 |
21 | ## 2. Group collaboration
22 |
23 | Each student should register your own github account. Group members should use **git and github** to collaborate.
24 |
25 | All the labs are done in the unit of group, i.e., a group only needs to submit one piece of code for each lab. However, each group member should make enough contribution to the lab. Teaching assistants will check the **git commit history** to evaluate each one’s contribution.
26 |
27 | ## 3. Code submission
28 |
29 | Each group should create a code repo for our course (create your own group's repo, do not push onto my course lab repo!). The group leader should send an email to TA telling us your group's lab git repo address. For example, https://github.com/group1/CloudComputingLabs.git`
30 |
31 | **All the lab code should be submitted through pushing to your group's github code repo.** Teaching assistants will checkout your commit, and read and test your codes from the above repo address you provided us. The code of different lab should be in different folders, named Lab1/Lab2/Lab3/Lab4, respectively (following the same structure of this repo). Please note that your lab folder name should be exactly same as above (be careful about the first capital letter and no space before the number), otherwise your code may fail in our TAs' automatic testing scripts. All lab codes should be in the same course git repo of your group.
32 |
33 | Please write a README.md to each lab code folder, briefly introducing how to run your lab code (including how to set the environment, provide the input, and explain the output, etc.). Keep the README short and clear! Also, your code should be well commented so that other people can understand without asking you.
34 |
35 | ## 4. Environment requirement
36 |
37 | ### 4.1 OS requirement
38 |
39 | All the labs should be tested and runnable on UNIX-like operating systems, such as Linux distributions (e.g., Ubuntu, CentOS) and MacOS. We highly recommend you to use Linux distributions such as Ubuntu.
40 | If you only have windows PC or laptops, install a UNIX VM and do experiments on the VM.
41 |
42 | ### 4.2 Programming language
43 |
44 | Any programming languages are permitted in all labs, such as C/C++, Java, Go, Python, Perl. But for performance consideration, we highly recommend you to use C/C++ or Go !!!
45 |
46 | ### 4.3 Try to only use standard API
47 |
48 | To make your program portable, try your best to only use standard & widely available functions and normal libraries (such as `glibc`, `C++ STLs` and some typical math libraries). All the labs should only use standard system API defined by POSIX specification or Linux man page specification. We prefer to use standard POSIX API, so your code can be easily runnable on various kind of UNIX-like systems (instead of only on Linux).
49 |
50 | ## 5. Grading
51 |
52 | Grading details are specified in each lab's instruction document, please carefully read them [Lab1](Lab1/README.md), [Lab2](Lab2/README.md), [Lab3](Lab3/README.md), [Lab4](Lab4/README.md).
53 |
54 | Besides, we have the following 3 overall grading requirements applicable to all the 4 labs:
55 |
56 | 1. **DO NOT copy** others' code (either from the Internet or from your classmates), otherwise your group (every member and the leader) will got **zero point** in the lab. However, we encourage to communicate with other group and learn from each other. But do remember to write the code yourself and not copy.
57 | 2. **DO NOT miss the deadline**, otherwise your group (every member and the leader) points will be reduced accordingly.
58 | 3. Typically, your group (every member and the leader) will get same points in each lab, unless we find severely **unfair contribution** in the git commit history. In the overall grading, the leader will get some more points as bonus.
59 |
--------------------------------------------------------------------------------