Connection Manager

[0yech]

Connection Manager

The main event loop. Essentially, it's here for routing requests and responses to clients.
Could be part of the main function directly or executed as part of another function.

socket, send, recv, bind, connect, listen, accept, poll, epoll, kevent, htons, htonl, ntohs, noths

Responsibilities

The Connection objects live here.
Receives incoming connections and manages existing ones.
Listener objects manage incoming connections and create Connection objects accordingly. These are stored in a map of listening socket to listener. Depending on which socket was contacted, it looks up the right Listener and asks it to create a new Connection using the new connection socket issued by the listener socket.

Calling Parsing

Connection objects contain a Request being built/processed, and a Response being sent.
As data comes through sockets, the parser will have to be called every time with that data chunk and a reference to the incomplete Request object.
The parser will then set the request status indicating whether it needs more data from the client or if the Request is ready to be processed.

Processing Requests

Sends incoming requests to the Request Processor as a Request object.
Receives the requested data back from the Request Processor and sends them to the relevant socket

Deleting Connections

When a Connection object signals through its return status that it is ready to be closed, the main loop removes its fd from the polled array and deletes the Connection object, in that order.

Receiving/Sending Data

This is where all the sockets fun happens: poll, accept and send.
The loop polls all active sockets, as well as CGI fds to read the content from and send it to the client that requested it.

CGI

When receiving an fd from the Request Processor for CGI, it stores it in a map from fd to Connection object.
This makes it easy to lookup which connection to send the data to when the fd becomes readable, and clearly marks which fds are for CGI and which are sockets.

Error Pages

When the Request Processor (or some other error happens), the Connection Manager sends a pre-made error page, or checks the error_page directive to know where to pull the page from.

[stellaaash]

How are we going to distinguish between listener sockets and connection sockets? When receiving an event through epoll, we know which socket it is, but it's just a number. How do we know what do with that event? Is it a new connection coming in, or data from an already existing one?

In my plan, there would be Listener and Connection objects that would each hold their specific socket. If we implement a common interface via virtual functions, we could just iterate on listeners and connections, find which one holds the right socket, then call a function to handle the event on that socket.
If it's a Listener, that function would create a new connection. If it's a Connection, it would receive the data, call the parser, etc. The point is that both classes should have the same interface to be able to call it the same way, regardless of whether the actual object is a Listener or a Connection.

[0yech]

"If we implement a common interface via virtual functions, we could just iterate on listeners and connections"

close enough, welcome aboard IHandlers