[http-server] Create an HTTP server with Seastar

[ndragazis]

The goal is to create a kv store that presents an HTTP REST API and uses the Seastar framework. What primitives does Seastar provide to create an HTTP server?

[ndragazis]

Let's start from the httpd application in the Seastar repo: https://github.com/scylladb/seastar/blob/master/apps/httpd/main.cc

The server utilizes the http library. The interface lives in include/seastar/http/httpd.hh. Main objects:

• http_server: The HTTP server object
• http_server_control: Helper class to control an http_server
• Handlers:
  • handler_base
  • function_handler: Get a lambda expression in the constructor. Calls the lambda to get the result.
  • directory_handler: Translates path parameter into a file path and returns file contents.
  • file_handler: Maps a single file to a URL and returns file contents.
• Routes: Request dispatching mechanism
  • Supports two decision mechanisms: exact match, matching rules

I notice that the httpd application spawns the http_server object inside a Seastar thread (see seastar::async()). However, the assignment recommends using Seastar coroutines.

[ndragazis]

Seastar Threads vs Coroutines

Coroutines require C++20 and a supporting compiler. The Dockerfile installs g++ 13.2.1. This does support C++20, however, we have to add the flag -std=c++20 in CFLAGS.

Documentation for Seastar Threads: https://github.com/scylladb/seastar/blob/master/doc/tutorial.md#seastarthread Documentation for Seastar Coroutines: https://github.com/scylladb/seastar/blob/master/doc/tutorial.md#coroutines

My understanding is that they both provide a synchronous programming model (unlike futures and promises), and they differ on how they implement blocking behavior.

• Threads have a stack (just like in my userspace threading library). When they block, Seastar just stores the CPU context and switches to another thread.
• Coroutines do not have a stack. To support blocking behavior, the compiler allocates they activation records on the heap, so that they can be resumed later. (same as Python coroutines)

So, coroutines scale better than threads since they consume less memory, but threads run faster than a long sequence of nested coroutines, since each coroutine call would require a heap allocation request.