Overview

A Simple HTTP Server Implementation that Efficiently Parses, Routes and Responds to HTTP Req.

Define a route, i.e POST /data , and get back the data with full control over each header sent.

What Problem Does This Solve?

Modern web frameworks carry a heavy abstraction tax for general-purpose I/O. For example, Node.js relies on libuv, which is highly capable but fundamentally trades raw networking throughput for cross-platform safety. Because it manages a generalized event loop, libuv defaults to level-triggered polling and standard IPC socket sharing.

cog-server solves this by stripping away the general I/O manager and optimizing for networking, utilizing edge-triggered polling (EPOLLET) and kernel-level load balancing (SO_REUSEPORT) for zero-overhead concurrency

How This Works

Overview

• The main thread sets up the threads and a custom eventfd file descriptor for signaling each thread. Each worker thread has its own memory pool, so once a memory block is warmed up, subsequent calls to malloc can be avoided.

• Each worker thread has its own socket, using the kernel feature SO_REUSEPORT. When a new connection arrives, the kernel applies hash-based load balancing to distribute the requests among workers.

• Once a request is received, its file descriptor is flagged as non-blocking so that we can asynchronously process it. The epoll_wait loop catches this fd and starts to process it. When an I/O buffer reaches its limit, it gives control back to epoll_wait so we can process another request in the meantime.

HTTP State Machine

Routing

• The routing logic follows a plugin architecture. The route file is separate from the core server logic, so we can avoid compiling server each time a route needs to be changed.

• Routes have their own memory arena, which is automatically freed at the end. Because of this, the user does not have to worry about memory management.

• Routes defined in routes.so are loaded into a hashmap when the server starts. In the future, this can be extended so that we can hot-reload routes by sending a SIGRTMIN signal without having to restart the server.

Disclaimer

NOTE: This Project is definitely not trying to be a replacement for Node.js or Nginx those are battle-tested production servers and Nginx uses almost the same philosophy as this project. As a matter of fact, this project was inspired by that. This is just a POC and mainly a challenge to see if I could make something like that or not

Benchmarks

NOTE: Benchmark was done using wrk -t4 -d30s -c<setting_here> on test page

• Low Traffic was testing -c50
• High traffic was tested using -c1000
• Slow Traffic was tested using -c1000 through external router

Throughput

Latency

Dependencies

• This project uses arena, in order to handle arena allocations and hashmap.c for hashmap implementation.

• Otherwise, it is a very basic C project only dependent on linux syscalls and libc.

Batteries Not Included

Well...that's not strictly true. There are some extremely basic routes defined in routes/routes.c. You can setup your own routes there too.

Getting Started

Installation

You can download the pre-compiled binaries from the Releases page, or easily build the project from source using make.

Compilation

Available Make Options:

• all: compiles routes.so and server
• debug: build server-debug binary
• routes: builds routes only
• server: compiles server only

To compile everything just run make all

Config

To keep the server footprint as lightweight as possible, configuration is managed exclusively via environment variables.
Available Options:

• PORT
• BACKLOG

Recommended way to change settings: $: PORT=49153 ./cog-server

Note: You only need to provide variables if you want to change the default settings. For casual use, simply running ./cog-server will just work!

License

This is an MIT-Licensed project.