Skip to content
master
Go to file
Code

Latest commit

 

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
src
 
 
 
 
 
 
 
 
 
 

readme.md

modserver is an HTTP/1.1 application server. Applications are loaded at runtime from a configuration file. The server exports an API for use by applications to interpret requests and generate responses. Modules provide support for loading applications written in a variety of programming languages.

Here is an example application that writes a message to the user using the C API:

#include "modserver.h"

int run(servlet *s)
{
  rprintf(s, "hello from C");
  return 0;
}

Building

modserver builds on at least the following platforms: DragonFly BSD, FreeBSD, GNU/Linux, illumos, Mac OS X, NetBSD, and OpenBSD. Run make or gmake depending on the platform.

Individual modules may fail to build if their dependencies are not found. This is normal and does not affect the building of the server. Read the Makefile to get a sense for what is required to build each module.

Dependencies

A copy of all build dependencies are included in source form in the dep directory. Modules may require additional dependencies.

Usage

modserver config.conf

Configuration

See config.conf for an example configuration file and config.lua for the available configuration options.

The server listens on port 8080 by default: http://127.0.0.1:8080/

API

The C API is documented in modserver.h.

See the api directory for bindings for other languages.

Languages

There are example hello world applications in a variety of programming languages:

See the module directory to learn how to add support for another language.

Design

The design is a traditional forking server. Each concurrent request is handled by a separate process. A new process is created when all processes are busy handling a request. A process handles many requests to avoid the overhead of forking on each request. An idle process exits after five seconds to free its resources.

Applications are free to use blocking I/O because the operating system schedules the processes. A crash while handling a request does not affect other requests. The server reports the crash and continues running. One tradeoff with this design is the memory usage increases with the number of concurrent requests as more processes are created.

Feedback

Email eric@ers35.com or post a GitHub issue to give feedback.

Known Issues

  • Go servlets panic on Mac OS X.
  • Go servlets sometimes deadlock on runtime.futexsleep.
  • Ruby servlets sometimes crash.

About

modserver is an HTTP/1.1 application server.

Topics

Resources

License

Releases

No releases published
You can’t perform that action at this time.