Merge pull request #10 from Shibin-Ez/master

Minor corrections on Roadmap till stage 12

Author: Shibin-Ez

docs/roadmap/phase-1/stage-10.md

@@ -34,9 +34,9 @@ Along with modifying the existing modules to enable data transfer through pipes,
 
 Three new structs are introduced here. The `xps_pipe_s`  struct includes the buffer and the maximum threshold. The `xps_pipe_source_s` and `xps_pipe_sink_s` structs includes the `ready`/`active` flags and callback functions. Earlier the callback functions were called based on the `read_ready` / `write_ready` flags of connection , here it would be based on the status of source/sink and whether the pipe is readable/writable. A pipe is readable if the length of `buff_list` greater than `0` and writable if its length less than the maximum threshold.
 
-The callback functions in `connection.c` are modified to ensure the working of source-sink system. The `connection_source_handler()` reads the data using `recv()` and writes it to pipe, whereas the `connection_sink_handler()` reads the data from pipe and `send()`.
+The callback functions in `xps_connection.c` are modified to ensure the working of source-sink system. The `connection_source_handler()` reads the data using `recv()` and writes it to pipe, whereas the `connection_sink_handler()` reads the data from pipe and `send()`.
 
-Here, the timeout in the `epollwait()` is set according to the existence of ready pipes. A ready pipe indicates that some operation has to be done on that - write into, read from , destroy. The availability of ready pipe leads to the timeout being set to 0, which results in a non-blocking call as discussed earlier.
+Here, the timeout in the `epoll_wait()` is set according to the existence of ready pipes. A ready pipe indicates that some operation has to be done on that - write into, read from , destroy. The availability of ready pipe leads to the timeout being set to 0, which results in a non-blocking call as discussed earlier.
 
 In Stage 6, we have discussed the issue of accumulating nulls in the events,connections and listeners list, here we would be filtering those.
 
@@ -782,7 +782,7 @@ void filter_nulls(xps_core_t *core) {
 ```
 :::    
 
-- `handle_epoll_events()`  -  Replaces the existing `xps_loop_run()`,  this function would be invoked from the new `xps_loop_run()`. It iterates thorough the events and corresponding call back functions are called based on epoll notification. This is added to simplify the new `xps_loop_run()`.
+- `handle_epoll_events()`  -  Replaces the epoll events iteration logic from `xps_loop_run()`,  this function would be invoked from the new `xps_loop_run()`. It iterates through the events and corresponding call back functions are called based on epoll notification. This is added to simplify the new `xps_loop_run()`.
 ::: details **expserver/src/core/xps_loop.c -** `handle_epoll_events()`
     
 ```c

docs/roadmap/phase-1/stage-11.md

@@ -101,14 +101,14 @@ void listener_connection_handler(void *ptr) {
     // Creating connection instance
     ...
 
-    // TEMP
+    // Handle connection based on listener port (upstream or direct)
     if (listener->port == 8001) {
      
       /* create upstream connection */
       /*create pipe connection to  client source and upstream sink for the listener*/
       /*create pipe connection to upstream source and client sink for the listener*/
     } else {
-    /* same as previous stages*/
+      /* same as previous stages*/
 
     }
     

docs/roadmap/phase-1/stage-12.md

@@ -106,7 +106,7 @@ Also declare the newly created function in utility.h
 
 ### `xps_file.h`
 
-The code below has the contents of the header file for `xps_file`. Have a look at it and make a copy of it in your codebase.
+The code below has the contents of the header file for `xps_file.c`. Have a look at it and make a copy of it in your codebase.
 
 :::details **expserver/src/disk/xps_file.h**
     
@@ -225,7 +225,7 @@ Several file system-related C standard library functions are used to handle file
 
 `errno` determines the specific error when an operation fails. In case of `fopen()`, `EACCES` indicates a permission denied error and `ENOENT` indicates the specified file or directory doesn't exist.
 
-The functions in xps_file.c are given below:
+The functions in `xps_file.c` are given below:
 
 1. **`xps_file_create()`**
 
@@ -362,16 +362,16 @@ The second struct is for storing the key-value pairs of mime extensions and mime
 
 ## `xps_listener` Module - Modifications
 
-### `listener.c`
+### `xps_listener.c`
 
 As we have to serve file for the incoming connections on port 8002, the `listener_connection_handler` function has to be modified. The `xps_file_create` function is invoked for opening the file and creating a `xps_file_s` instance for it. The path of file to be opened is specified in the argument. Then pipe is created with the source that is attached to the file instead of that attached to connection.
 
 ```c
-if (listener->port == 8001) {
+    if (listener->port == 8001) {
       ....
     } else if (listener->port == 8002) {// [!code ++]
       int error;// [!code ++]
-      xps_file_t *file = xps_file_create(listener->core, "../public/sample.txt", &error);// [!code ++]
+      xps_file_t *file = xps_file_create(listener->core, "public/sample.txt", &error);// [!code ++]
       xps_pipe_create(listener->core, DEFAULT_PIPE_BUFF_THRESH, file->source, client->sink);// [!code ++]
     } else {
       ...

docs/roadmap/phase-1/stage-6.md

@@ -83,9 +83,6 @@ struct xps_connection_s;
 typedef struct xps_listener_s xps_listener_t;
 typedef struct xps_connection_s xps_connection_t;
 
-// Function typedefs
-typedef void (*xps_handler_t)(void *ptr);
-
 // Temporary declarations
 extern vec_void_t listeners;
 extern vec_void_t connections;
@@ -718,7 +715,6 @@ After compiling, it should give an output file named `xps`. Start eXpServer usin
 [INFO] main() : Server listening on port 8001
 [INFO] main() : Server listening on port 8002
 [INFO] main() : Server listening on port 8003
-[INFO] main() : Server listening on port 8004
 ```
 
 ::: tip NOTE

docs/roadmap/phase-1/stage-7.md

@@ -421,7 +421,7 @@ void xps_loop_run(xps_loop_t *loop) {
       if (curr_epoll_event.events & EPOLLIN) {
         logger(LOG_DEBUG, "handle_epoll_events()", "EVENT / read");
         if (curr_event->read_cb != NULL)
-          // Pass the ptr from loop_event_t to the callback
+          // Pass the ptr from loop_event_t as a parameter to the callback
           curr_event->read_cb(/* fill this */);
       }
     }
@@ -644,8 +644,8 @@ struct xps_connection_s {
   char *remote_ip;
 };
 
-xps_connection_t *xps_connection_create(int epoll_fd, int sock_fd, xps_listener_t *listener); // [!code --]
-xps_connection_t *xps_connection_create(xps_core_t *core, u_int sock_fd, xps_listener_t *listener);// [!code ++]
+xps_connection_t *xps_connection_create(int epoll_fd, int sock_fd); // [!code --]
+xps_connection_t *xps_connection_create(xps_core_t *core, u_int sock_fd);// [!code ++]
 void xps_connection_destroy(xps_connection_t *connection);
 void xps_connection_read_handler(xps_connection_t *connection); // [!code --]
 
@@ -669,6 +669,10 @@ Another major change is seen in how/who calls the [callback functions](<https://
 
 Now we pass the callback functions and pointer to the instance when calling `xps_loop_attach()`.
 
+:::tip NOTE
+We have renamed `xps_listener_connection_handler` to `listener_connection_handler` and `xps_connection_read_handler` to `connection_read_handler` as these two functions are no longer global.
+:::
+
 In the case of `xps_listener`:
 
 ::: details **expserver/src/network/xps_listener.c**
@@ -697,7 +701,7 @@ void listener_connection_handler(void *ptr) { // [!code ++]
   assert(ptr != NULL); // [!code ++]
   xps_listener_t *listener = ptr; // [!code ++]
 
-  /* same code from xps_listener_connection_handler() */
+  /* same code logic from xps_listener_connection_handler() */
 
 }
 ```
@@ -799,7 +803,6 @@ Since we did not modify the functionality of the server, this milestone will is
   #include <netdb.h>
   #include <netinet/in.h>
   #include <stdio.h>
-  #include <stdlib.h>
   #include <string.h>
   #include <sys/socket.h>
   #include <sys/types.h>
@@ -827,7 +830,7 @@ Since we did not modify the functionality of the server, this milestone will is
   return -1;
   }
 
-  if (connect(sock, (struct sockaddr* )&serv_addr, sizeof(serv_addr)) < 0) {
+  if (connect(sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) {
   perror("Connection failed");
   return -1;
   }
@@ -875,7 +878,7 @@ Since we did not modify the functionality of the server, this milestone will is
 
 **What is going on here?**
 
-The `sender` only sends data to eXpServer. It does not `recv()` data. Thus, when eXpServer is trying to send the reversed string back, it is not getting received. This will cause the kernel buffer to fill up. When the kernel buffer is full the call to `send()` will block the process as we are dealing with blocking network sockets. The process is blocked till the data in the kernel buffer is cleared. However this will not happen as `sender` does not receive any data. Thus the eXpServer process will block leading to no more connections being served.
+The `sender` only sends data to eXpServer. It does not `recv()` data. Thus, when eXpServer is trying to send the reversed string back, it is not getting received. This will cause the kernel buffer to fill up. When the kernel buffer is full, the call to `send()` will block the process as we are dealing with blocking network sockets. The process is blocked till the data in the kernel buffer is cleared. However this will not happen as `sender` does not receive any data. Thus the eXpServer process will block leading to no more connections being served.
 
 In a real life situation where the rate at which eXpServer is writing to a TCP socket is more than the rate at which data is received by the TCP client, the kernel buffer can fill up resulting in the server process being blocked intermittently. This leads to inefficient serving of connections.
 

docs/roadmap/phase-1/stage-8.md

@@ -204,7 +204,7 @@ Make necessary changes in `xps_loop.c`. Here are a few hints:
 ### Modifications to `xps_connection` Module
 
 - Similar to `connection_loop_read_handler()`, add `connection_loop_write_handler()` and `connection_loop_close_handler()` in `xps_connection.c` .
-- In `connection_close_handler()` destroy the connection instance.
+- In `connection_loop_close_handler()` destroy the connection instance.
 - Currently in `connection_loop_read_handler()` we `recv()` from the connection socket, reverse the string and `send()` it back. However, from now on `connection_loop_write_handler()` will be invoked when the socket is available to be written to. Hence, `send()` should be invoked within `connection_loop_write_handler()` .
 - Therefore, we need to buffer the reversed strings somewhere till it is ready to be sent. For that we will use an `xps_buffer_list` .
 

docs/roadmap/phase-1/stage-9.md

@@ -116,7 +116,7 @@ void connection_write_handler(void* ptr) {
 }
 ```
 
-Initialize `send_handler` and `recv_handler` fields of the `xps_connection_s`  structure in the `xps_connection_create` function using `connection_read_handler` and `connection_write_handler` callbacks .
+Initialize `send_handler` and `recv_handler` fields of the `xps_connection_s`  structure in the `xps_connection_create` function using `connection_write_handler` and `connection_read_handler` callbacks respectively.
 
 To enable epoll edge triggering mode we have to set the EPOLLET flag.  EPOLLET flag is used to explicitly request the epoll to notify only when an FD changes its state. We have to pass EPOLLET along with EPOLLIN and EPOLLOUT flags in `xps_loop_attach` .