Added phase 2 overview and updated guides

Author: NandanaDV

docs/guides/index.md

@@ -15,9 +15,9 @@ The guides feature supplementary documentation intended for your reference as yo
 - ✅ [Coding Conventions](/guides/resources/coding-conventions)
 - ✅ [TCP/IP Model](/guides/resources/tcp-ip-model)
 - ✅ [TCP Socket Programming](/guides/resources/tcp-socket-programming)
-- 🟡 [UDP Socket Programming](/guides/resources/udp-socket-programming)
+- ✅ [UDP Socket Programming](/guides/resources/udp-socket-programming)
 - ✅ [Process and Threads](/guides/resources/process-and-threads)
-- ⚪ [System Calls](/guides/resources/system-calls)
+- ✅ [System Calls](/guides/resources/system-calls)
 - ✅ [Linux epoll](/guides/resources/introduction-to-linux-epoll)
 - 🟡 [Linux epoll tutorial](/guides/resources/linux-epoll-tutorial)
 - 🟡 [Blocking & Non-Blocking Sockets](/guides/resources/blocking-and-non-blocking-sockets)

docs/guides/resources/linux-epoll-tutorial.md

@@ -95,22 +95,22 @@ int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
     
     The fields of the `epoll_event` structure are as follows:
 
-- **events** - It is of type `uint32_t`, which refers to an unsigned 32 bit integer. This field is used to specify which events the file descriptor (FD) should be monitored for in the epoll instance. The major available events include,
+- `events` - It is of type `uint32_t`, which refers to an unsigned 32 bit integer. This field is used to specify which events the file descriptor (FD) should be monitored for in the epoll instance. The major available events include,
     
     `EPOLLIN` - used for read operations
     
     `EPOLLOUT` - used for write operations 
     
     `EPOLLLET` - requests edge triggered notifications for the FD
     
-- **data** - This field is a union that specifies the data that kernel should save and return when the file descriptor becomes ready.
+- `data` - This field is a union that specifies the data that kernel should save and return when the file descriptor becomes ready.
 
-      The fields of the union `epoll_data` are as follows: 
+    The fields of the union `epoll_data` are as follows: 
 
-- **void *ptr** - A pointer to some user-defined object or data. This is useful when we need to store a reference to a custom object (such as a structure) that is associated with the event.
-- **int fd** - The file descriptor we are interested in and on which events are being monitored.
-- **uint32_t u32** - A 32 bit unsigned integer which is used to store flags or timeout values.
-- **uint64_t u64** - A 64 bit unsigned integer that can store large values required for specific event processing flags or timeout values.
+- `void *ptr` - A pointer to some user-defined object or data. This is useful when we need to store a reference to a custom object (such as a structure) that is associated with the event.
+- `int fd` - The file descriptor we are interested in and on which events are being monitored.
+- `uint32_t u32` - A 32 bit unsigned integer which is used to store flags or timeout values.
+- `uint64_t u64` - A 64 bit unsigned integer that can store large values required for specific event processing flags or timeout values.
 
 When the `epoll_ctl()` function call is successful, it returns `0`. If an error occurs, it returns `-1`, and the global variable `errno` is set to indicate the specific error that occurred. Some common errors include
 

docs/guides/resources/tcp-socket-programming.md

@@ -27,7 +27,7 @@ The working of [TCP protocol](https://en.wikipedia.org/wiki/Transmission_Control
 
     On the receiving side the incoming packets need not be in the same order as send by the other side. The packets may arrive out of order due to network congestion or other related issues. Thus it is essential to reorder the data correctly at the receiving side. There is a receive queue and an out-of-order queue maintained by the kernel for each connection socket.   When packets arrive out of order, they are placed in the **out-of-order queue** until the missing packets arrive, and then they are reordered and moved into the receive queue. When the application calls `recv()`, it requests a specific amount of data from the receive queue. If the queue is empty, `recv()` blocks (unless the socket is in non-blocking mode) until data arrives. Otherwise, the kernel copies the requested data from the receive queue to the user-space buffer, returning success once the copy is complete. If the available data is less than requested, `recv()` returns only what is available.  These mechanisms, along with sequence numbers, ACKs, retransmissions, and proper queue management, ensure TCP's reliability and in-order data transfer.
 
-    Note that in UDP, which is a connection-less protocol,  there is no formal connection setup using `listen()`, `connect()`, or `accept()`.   Hence each packet must carry explicit addressing information.  The sender must specify the target address in each `sendto()` call, and the receiver retrieves the sender's address using `recvfrom()` to know where to respond. (More details on UDP is provided in the UDP documentation.)
+    Note that in UDP, which is a connection-less protocol,  there is no formal connection setup using `listen()`, `connect()`, or `accept()`.   Hence each packet must carry explicit addressing information.  The sender must specify the target address in each `sendto()` call, and the receiver retrieves the sender's address using `recvfrom()` to know where to respond. (More details on UDP is provided in the [UDP documentation](/guides/resources/udp-socket-programming).)
 
 3. **Connection Termination:** The connection is closed gracefully using a four-way handshake **(FIN, ACK, FIN, ACK)**, allowing both parties to end communication without data loss. The termination process typically begins when one side (typically the client) initiates the termination by calling the `close()` system call. As a result the client side kernel send a **FIN** packet to the server. Upon receiving the **FIN**, the server side kernel acknowledges it by sending an **ACK** packet back to the client. At this point, the connection becomes **half-closed**, meaning the client can no longer send data, but the server can still transmit data to the client and the client can receive the data from server. This half-closed state ensures that all the pending data reaches the destination before the connection fully terminates. Once the server completes its data transmission, it must invoke `close()` to intimate the server kernel of its willingness to close the connection.  At this point, the server side kernel sends its own **FIN** packet to the client. The client, upon receiving this **FIN**, responds with a final **ACK** packet,and releases the resources associated with the client socket. After receiving the final **ACK**, the resources associated with the server socket gets released.
 

docs/roadmap/index.md

@@ -46,9 +46,9 @@ The eXpServer project comprises 24 stages, organized into 5 phases. Prior to the
 
 ### Phase 2: Implementing HTTP support
 
-- [Overview](phase-2/)
+- 🟡 [Overview](phase-2/)
 - 🟡 [Stage 14: HTTP Request Module](phase-2/stage-14)
-- [Stage 15: HTTP Response Module](phase-2/stage-15)
+- 🟡 [Stage 15: HTTP Response Module](phase-2/stage-15)
 - [Stage 16: Config Module](phase-2/stage-16)
 - [Stage 17: Directory Browsing](phase-2/stage-17)
 

docs/roadmap/phase-2/index.md

@@ -1 +1,21 @@
 # Phase 2: Overview
+## Recap of Phase 1
+
+After the completion of phase 1, we have built the basic version of eXpServer, which is capable of handling reverse proxy and static file serving. On progressing through each stages in phase 1, we have implemented various modules that form the building blocks for the server. Let’s have a quick recap of the stages in phase 1. 
+
+- In stage 6, we have created the listener and connection modules. Listener module deals with creation of listening socket and handling read events on the listening socket. It’s also responsible for creating a connection instance for the connected client. The connection module creates instances for the TCP connections and deals with sending and receiving of data.
+- In stage 7, core and loop modules were created. Core module acts as a container for all other modules of eXpServer. Loop module acts as the engine for the server, which handles all the events occurring on the TCP sockets attached to epoll.
+- In stage 8, we have made the sockets non blocking.
+- In stage 9, we have implemented epoll in edge triggering mode, which has improved the CPU utilization.
+- In stage 10, we have seen pipes for data exchange between modules. Pipes have improved the overall memory utilization.
+- In stage 11, the upstream module was created. All the client requests from port 8001, was directed to the upstream server using the upstream module.
+- In stage 12, serving of static files was implemented. All the client requests on port 8002, was for file serving. It was implemented with the help of file module.
+- In stage 13, we have created a new module named session, which acts as an intermediary between client and either upstream or file module.
+
+## What to expect in Phase 2
+
+In phase 1, we have built a functional eXpServer that supports the basic functionalities of reverse proxying and static file serving. We have used TCP protocol as the basic protocol for data transmission. But till now both the client and server was running and communicating with each other via a terminal. Even though TCP is ensuring reliable data transmission, but it cannot define how data is formatted or interpreted, making it impossible to communicate meaningfully with clients. It lacks the necessary capabilities to effectively serve clients, manage interactions, and provide a meaningful user experience. 
+
+Thus there comes a need to incorporate the application layer protocols in eXpServer, to have a better client interaction and user experience. Without an application layer protocol like HTTP, the server cannot deliver web pages or content in a way that browsers can understand. HTTP is the one of the most important application layer protocol used for enabling web communication. All communication from a browser (client) to the server and vice versa would be in the form of HTTP messages. In this phase, we will introduce the notion of HTTP, and make our server HTTP compatible. 
+
+HTTP requests and responses form the important part of modern web, that enables communication between clients and servers. An HTTP request is sent by a client to the server requesting a resource typically a web page, image or data. An HTTP response is the server’s reply to an HTTP request. In this phase new modules will be created for supporting HTTP features. We will implement an HTTP parser, that can parse the incoming client requests to a structured HTTP request. An http request module and http response module would be created for handling the HTTP requests and HTTP responses.