Server provide HTTP technologies integrations under a common interface. They inherit from GLib.Application, providing an optimal integration with the host environment.
The following implementations are available:
- libsoup built-in HTTP server
- FastCGI
Basically, you have access to a DBusConnection to communicate with other process and a GLib.MainLoop to process events and asynchronous work.
- an application id to identify primary instance
startup
signal emmited right after the registrationshutdown
signal just before the server exits- a resource base path
- ability to handle CLI arguments
GLib.Application will automatically register to the session DBus bus, making IPC (Inter-Process Communication) an easy thing.
It can be used to expose runtime information such as a database connection details or the amount of processing requests. See this example of DBus server for code examples.
To identify your workers, you can use the set_application_id
function.
server.set_application_id ("worker");
This can be used to request services and communicate between your workers and interact with the runtime.
var connection = server.get_dbus_connection ()
connection.call ()
Each server implementation can optionally take arguments that parametrize their runtime. Generally, you can set the following options:
- a socket path or a TCP port
- backlog
- inactivity timeout
If you build your application in a main block, it is not possible to obtain the CLI arguments, so you must write your code in a main
function.
public static int main (string[] args) {
var app = new Router;
app.get ("", (req, res) => {
res.write ("Hello world!".data);
});
return new Server (app).run (args);
}
If you specify the --help
flag, you can get more information on the available options.
build/examples/fastcgi --help
Usage:
fastcgi [OPTION...]
Help Options:
-h, --help Show help options
--help-all Show all help options
--help-gapplication Show GApplication options
Application Options:
-s, --socket path to the UNIX socket
-p, --port TCP port on this host
-b, --backlog=0 listen queue depth used in the listen() call
-t, --timeout=0 inactivity timeout in ms
In some context, you do not want to serve your application over a TCP socket, but just a local socket. Either this or --port
can be specified, but not both.
This is the TCP port on which the application will be exposed on the local host.
The backlog correspond to the depth on the listen
call and is used if you have multiple listener on a socket.
An inactivity timeout can be set to exit automatically after a certain amount of milliseconds if no request is being processed.
The server keeps track of the number of processing requests with hold
and release
from GLib.Application. When the amount reaches 0, the server will exit automatically after the value of the inactivity timeout.
This option is enabled if the default timeout value is greater than 0.