Main Page   Data Structures   File List   Data Fields   Globals   Related Pages  

PDepp Webserver Programmer's Manual

PDEPP Webserver pre 0.3.1

Introduction To The Code

License & Disclaimer

PDEPP Webserver pre 0.3.1
Copyright (C) 2001 by Christian Hoenig & Gunter Ohrner
PDEPP Webserver comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. For more details see the GNU General Public License Version 2 (

Overview / Design Goals

One major goal while designing the PDepp Webserver was to keep the whole program as modular as possible, with well defined, consistent interfaces and with each module knowing the least possible about any other module. It should be possible to replace the server's protocol parser or network layer with no changes to other parts of the server.

Furthermore it should be possible for several alternative implementations of a given module to coexist and for the "right" implementation to be selected dynamically at runtime (eg. choosing a different request handler depending on the URLs path prefix or file extension, details see below), however this has not been implemented yet. Adding it should not be too hard and would mainly consist of wrapping the existing module interfaces into structs (using function pointers) to allow them beeing put in lists.

Most modules are ADTs, very closely resembling the the structure of classes in object oriented programming languages. This way we tried to achieve the neccessary level of abstraction and data encapsulation.

Key Features From The Programmer's / Contributor's Point Of View

Please refer to the Bug List and the Todo List in this manual for known bugs and limitations.

Latest Changes

0.3 Gargle Blaster

0.2 Improbability Drive 0.1 Initial Release

Syntactical Programming Conventions

Altough we understand that there is a myriad of ways to write syntactically correct code and many of these may be help- and / or useful in some cases it is of extreme importance that only exactly ONE is used within one specific program. There are only very few things worse than mixed coding styles in one program...

The following rules and conventions are used within PDepp Webserver's code.

Naming Conventions:

Structural Conventions:

The PDepp Webserver's Structure

The PDepp Webserver's architecture is based on several independant layers. Each layer has (or at least should have ;-) a well-defined interface and task scope. Each layer does only know about and communicate with it's direct neighbours and is designed to be easily replaceable by an alternate implementation without affecting any other layer it's communicating to.

The server's basic structure can be seen best in the following overview diagram. The "layers" are aligned from the left to the right as we simply could not agree on the Server Core being top or bottom of the architecture ;-). Having this diagram's layout in mind we will refer to a layer's "left neighbour" and "right neighbour" throughout the rest of the manual.


PDepp Webserver's layered architecture

The Generic Layer Interface

Each layer has a predefined set's of methods it must implement. Unfortunately C has nothing resembling C++'s pure virtual classes or Java's Interfaces which would be a nice way to enforce a consistent interface so in our case it's completely up to the Layer's programmer to stick to the standard.

An important thing to note is that the right neighbour of ANY layer is passive - it waits for a request or notification from its left neighbour before doing anything. In this context the Client could be seen as the Server Core's left neighbour.

Each Layer has to provide the following methods (the Server Core being a slight exception as its "left neighbour" is non-standard as well by design):

The Server Core Layer

The Server Core is the connection multiplexer part of the PDepp Webserver. It listens for and accepts new connections, creating a new Connection Handler object to manage it. Additionally it waits for data arriving for currently active connections or for active sockets ready to send data and informs the corresponding Connection Handler by calling its chReceive or chSend functions.

The Server Core's interface is declared in server.h. Its currently only implementation resides in server.c , supports TCP/IP sockets and has not yet been converted to an ADT.

Both the connection multiplexer and the Connection Handler should be independant of the actual kind of connection used (TCP sockets, unix domain sockets, named FIFOs, etc...) and work only on file descriptors. Maybe an additional abstraction layer for different kinds of communication should be introduced... (eg. renaming the Server Core to "Connection Multiplexer" and creating a new Server module / layer containing the code to establish a "server socket" and accepting new connections.) \n

The Connection Handler Layer

A Connection Handler represents a single connection to a client. It's responsible for non-blocking reads into the receive buffer and for writing chunks from the send buffer to the client. A connection handler associates a connection with a protocol Handler.

The Connection Handler's interface is declared in conn_handler.h. Its currently only implementation resides in conn_handler.c and supports client connections through file descriptors.

The Protocol Handler Layer

A Protocol Handler is responsible for "understanding" the client's requests and giving the right answers (ofter with the help of a Request Handler). The whole protocol parser / generator code is encapsulated in modules belonging to this layer.

The Protocol Handler's interface is currently declared in http.h . Its currently only implementation resides in http.c , supports a subset of the HTTP 1.0 protocol and virtually no HTTP 1.1 extensions.

Possible alternative implementations could include a Protocol Handler supporting the FTP protocol or similar (NNTP, ...).

The Request Handler Layer

A Request Handler is responsible for actually executing the request of the client as understood by the Protocol Handler and returning the data resulting from processing the request.

The Request Handler's interface is currently declared in reqhandler_file.h. Its currently only implementation resides in reqhandler_file.c and supports reading static files from disk.

Possible alternative implementations could include a Request Handler supporting CGI scripts or database querys.

Other Modules / Non-Layer Modules

All additional modules in alphabetical order:

Data type independant container templates in alphabetical order:

Generated on Fri Jan 25 22:40:30 2002 for PDepp Webserver by doxygen1.2.11.1 written by Dimitri van Heesch, © 1997-2001