DOCSEARCHbyAlgolia
Submit Docs

Digital Garden

website·Indexed 31 days ago

https://digital-garden-psi.vercel.app/

A personal knowledge base containing technical notes, including a guide to Webserv, a Doxygen quick guide, and solutions for examrank05 level0-bigint.

Tokens
2.3K
Snippets
8
Records
15
Agent score
74%

What's inside Digital Garden

  1. Webserv project architecture overview

    The Webserv project is structured around four primary classes that manage the lifecycle of a web server:

    • Service: The central orchestrator that links parsing, setup, and launch phases. It maintains the server list, client list, and the socket polling vector.
    • Parser: Responsible for reading .conf files and extracting server block configurations to instantiate Server objects.
    • Server: Represents a single server configuration block (e.g., server { ... }) and stores its specific parameters.
    • Client: Created upon each new connection; stores the associated server, the client's socket, and the received request.

  2. Implement an arbitrary precision unsigned integer class (bigint)

    Create a bigint class to store arbitrary precision unsigned integers, preventing precision loss when numbers exceed SIZE_MAX. The class must support addition, comparison, and 'digitshifting' (base-10 shifting). For example, a left shift of 3 on 42 results in 42000, and a right shift of 2 on 1337 results in 13. The class must be printable via the << operator in base 10 without leading zeros.
    // Required functionality:
bigint a(42);
bigint b(21);
bigint c = a + b; // Addition
c += a;          // Addition assignment
++b;             // Pre-increment
b++;            // Post-increment
b >> 10;        // Right digit shift
d <<= 4;         // Left digit shift assignment
(d == a);        // Equality comparison
(d <= a);        // Comparison
std::cout << a;  // Base 10 output

  3. Write Doxygen comments in C++ code

    Doxygen generates documentation from structured comments starting with /** and each subsequent line starting with *. Use specific keywords to define metadata:

    • @brief: A short description of the entity.
    • @param: Description of a function parameter.
    • @return: Description of the return value.
    • @file: Documents the filename.
    • @author, @version, @date: Metadata about the file's origin and version.
    /**
 * @file Client.cpp
 * @brief Description of the file
 * @version 0.1
 * @date 2024-10-30
 */

/**
 * @brief Brief description
 * 
 * @param input Description of the input parameter
 * @param number Description of the number parameter
 * @return int Description of the return value
 */
int Client::function(std::string input, int number) {
    return 0;
}

  4. Initialize and parse server configurations

    The first phase of the Webserv lifecycle involves parsing the configuration file to define server parameters:

    1. The Service class is instantiated with a path to server.conf.
    2. The Service constructor creates a Parser instance.
    3. The Parser analyzes each server {} block in the configuration file and creates a corresponding Server instance.
    4. These instances are stored in a serverVector, which is then retrieved by the Service class.

  5. Set up LaTeX for Doxygen PDF generation on macOS

    To generate PDF documentation, install MikTeX. It is recommended to configure MikTeX to install missing packages automatically to avoid manual dependency resolution.

    1. Install MikTeX from the official site.
    2. In the MikTeX app, go to: Settings > Package Installation > (...) automatically installed > Always.

  6. Set up server sockets for listening

    The setup() method in the Service class prepares the network interface for each server defined in the serverVector. For every server, the following system calls are executed in order:

    1. getaddrinfo(): Retrieve server address information.
    2. socket(): Create the socket file descriptor.
    3. bind(): Link the socket to the specified port.
    4. listen(): Set the socket to listening mode to accept incoming connections.
    5. The resulting socket is added to the pollingFdVector for monitoring.

  7. Process HTTP requests and send responses in Webserv

    The server processes incoming HTTP requests through the following workflow:

    1. Request Reception: The server receives an HTTP request (e.g., GET /index.html HTTP/2) in the _request variable.
    2. Parsing: The server parses the request to extract the Host (verifying its existence in the serversVector) and the HTTP Method (e.g., GET, POST, DELETE).
    3. Response Generation: The server constructs and sends a response consisting of:
      • Status Line: An HTTP version and status code (e.g., 200 OK or 404 Not Found).
      • Headers: Metadata such as Content-Type and Content-Length.
      • Body: The actual payload (HTML, JSON, etc.).
    HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 138

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

  8. Process HTTP requests and send responses

    Once a request is received in the Client instance's _request variable, the server processes it as follows:

    1. Parsing: The server identifies the Host header (verifying it exists in the serversVector) and the HTTP method (GET, POST, or DELETE).
    2. Response Generation: The server constructs a response consisting of:
      • Status Line: Result code (e.g., 200 OK, 404 Not Found).
      • Headers: Metadata such as Content-Type and Content-Length.
      • Body: The actual data (HTML, JSON, etc.).
    HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 138

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

  9. Manage socket events using poll() and PollingManager

    The launch() method runs an infinite loop that monitors sockets using the poll() system call. Because poll() only indicates that an event occurred without specifying which socket or event type, a PollingManager() is used to iterate through the pollingFdVector and handle the following events:

    • Error (POLLERR, POLLHUP, POLLNVAL): The connection is closed and an error message is handled.
    • Ready to Read (POLLIN):
      • Server Socket: If the socket is a listening server socket, accept() is called to create a new client socket. This new descriptor is added to pollingFdVector and a Client instance is created.
      • Client Socket: If the socket belongs to an existing client, recv() is used to read data into the client's _request variable.
    • Ready to Write (POLLOUT): Indicates the buffer is empty and the server can send data back to the client.

  10. Handle socket events using poll() in Webserv

    The Webserv project uses poll() to monitor sockets. The system handles three primary socket states:

    1. Error State: If a socket triggers POLLERR, POLLHUP, or POLLNVAL, the server handles the error and closes the connection.
    2. Ready for Reading (POLLIN):
      • Server Sockets: If the socket is listening (via listen()), the server calls accept() to create a new client socket. This new file descriptor is added to the pollingFdVector and a new Client instance is initialized.
      • Client Sockets: Data sent by the client is read using recv() and stored in the Client instance's _request variable.
    3. Ready for Writing (POLLOUT): Indicates the socket buffer is empty and ready to send data back to the client.