[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
We know, you usually don't read the documentation. Who does. But please, read at the very least this chapter. It contains information on the basic concepts. Larger parts of the manual can be used as a reference manual for the various servers.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
sleepless ~> gzip -cd serveez-0.1.5.tar.gz | tar xvf - |
sleepless ~> cd serveez-0.1.5 |
poll()
and this feature is
enabled the main file descriptor loop is done via poll()
.
This helps to work around the (g)libc's file descriptor limit.
Otherwise Serveez always falls back to the select()
system call.
sendfile()
system call.
Disabling it using `--disable-sendfile' provides a work-around
for bogus implementations of sendfile()
.
sleepless ~/serveez-0.1.5> sh configure --enable-opt |
sleepless ~/serveez-0.1.5> make |
sleepless ~/serveez-0.1.5> make install |
If you have problems building the package out of the box this is due to GNU libtool's inability to handle dynamic linking in most cases. That is why we recommend to try to configure the package with `--disable-shared' and/or the native compiler (if any). When the build process is not able to link against an existing Guile installation you can try to use the `--with-guile-source=DIR' configure option.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
sleepless ~> rpm -qiRl -p serveez-0.1.5-1.i386.rpm |
sleepless ~> rpm -Uvh serveez-0.1.5-1.i386.rpm \ [ --nodeps ] [ --prefix=/opt/serveez ] serveez #################### |
sleepless ~> rpm -ev serveez-0.1.5 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
sleepless ~> dpkg -I serveez_0.1.5_i386.deb sleepless ~> dpkg -c serveez_0.1.5_i386.deb |
sleepless ~> dpkg -i serveez_0.1.5_i386.deb |
sleepless ~> dpkg -r serveez |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When using the serveezopt package or playing around with the dynamic server module loader of Serveez you can tell the core API of Serveez (which is the `libserveez.[so|dll]' library) to use an additional load path to find these server modules. The environment variable `SERVEEZ_LOAD_PATH' holds this information. You can set it up via:
on Unices sleepless ~> export SERVEEZ_LOAD_PATH=/home/lib:/usr/local/lib or on Windows C:\HOME> set SERVEEZ_LOAD_PATH=C:\HOME\LIB;C:\USR\LOCAL\LIB |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When Serveez is started it reads its configuration from a file called `serveez.cfg' in the current directory and runs the server loop afterwards. Press ^C to abort the execution of this program. Serveez is not interactive and does not automatically detach from the terminal.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
-h, --help
-V, --version
-i, --iflist
-f, --cfg-file=FILENAME
-v, --verbose=LEVEL
-l, --log-file=FILENAME
FILENAME
for logging (default is stderr).
-P, --password=STRING
-m, --max-sockets=COUNT
-d, --daemon
-c, --stdin
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As noted above Serveez is configured via a configuration file which is by default `serveez.cfg' and can be set by passing the `-f' command line argument. When you pipe a file into Serveez or pass the `-c' argument on the command line the input stream will be used as configuration file no matter whether you passed a `-f' command line switch or not.
To make configuring more fun we did not invent yet another configuration file format. Instead we use a dialect of the Scheme programming language called GNU Guile (http://www.gnu.org/software/guile/). There is no need to be worried if you are not a programmer. What you have to do is really simple and this document shows you everything you need to know. We also provide many examples. However there are some simple concepts you have to understand. The following paragraphs will explain them.
The idea of the configuration file is this: Serveez starts, runs the configuration file (other applications usually just read them and remember the settings) and finally enters its main loop doing the things you wanted it to.
There are three things you have to do in the configuration file.
2.5.1 Define ports Port configuration definition 2.5.2 Define servers Server definition 2.5.3 Bind servers to ports How to bind servers to port configurations
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A port
(in Serveez) is a transport endpoint. You might know them
from other TCP or UDP server applications. For example: web servers
(HTTP) usually listen on TCP port 80. However, there is more than TCP
ports: we have UDP, ICMP and named pipes each with different options to
set. Every port has a unique name you assign to it. The name of the port is
later used to bind servers to it.
The following examples show how you setup different types of port
configurations. You start to define such a port using the Guile function
(define-port!)
. The first argument to this functions specifies the
name of the port configuration. The remaining argument describes the
port in detail.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
proto (string)
port (integer in the range 0..65535)
port
item determines the network port number on which TCP and UDP
servers will listen. Thus it does not make sense for ICMP and named pipes.
If you pass `0' Serveez will determine a free port in the range
between 1 and 65535.
recv (string or associative list)
recv
and send
item apply to named pipes only. The value can either be an associative
list or a simple filename. Using a simple filename leaves additional
options to use default values. They deal mainly with file permissions
and are described below.
send (string or associative list)
name (string)
permission (octal integer)
user (string)
group (string)
uid (integer)
uid
item or the user
item. Serveez will
complain about conflicting values.
gid (integer)
gid
item or the group
item. Serveez will croak
about conflicting values.
ipaddr (string)
device (string)
device
configuration item also refers to the IP address a server
can be bound to. It overrides the ipaddr
item. Valid values are
network device descriptions (probably no aliases and no loopback devices).
It applies to network ports (TCP, UDP and ICMP) only.
A note on device bindings: Device bindings are based on the
SO_BINDTODEVICE
socket layer option. This option is not available
on all systems. We only tested it on GNU/Linux (2.2.18 and 2.4.17 as of
this writing). Device bindings are very restrictive: only root can do it
and only physical devices are possible. The loopback device cannot be used
and no interface alias (i.e. `eth0:0'). A device binding can only
be reached from the physical outside but it includes all aliases for the
device. So if you bind to device `eth0' even `eth0:0' (and all
other aliases) are used. The connection has to be made from a remote
machine. The advantage of this kind of binding is that it survives
changes of IP addresses. This is tested for ethernet networks (i.e. eth*)
and isdn dialups (i.e. ippp*). It does not work for modem dialups
(i.e. ppp*) (at least for Stefan's PCMCIA modem). The problem seems to be
the dialup logic actually destroying ppp*. Other opinions are welcome.
Device bindings always win: If you bind to `*' (or an individual IP
address) and to the corresponding device, connections are made with
the device binding. The order of the (bind-server!)
statements
do not matter. This feature is not thoroughly tested.
backlog (integer)
backlog
parameter defines the maximum length the queue of
pending connections may grow to. If a connection request arrives with the
queue full the client may receive an error. This parameter applies to
TCP ports only.
type (integer in the range 0..255)
send-buffer-size (integer)
send-buffer-size
configuration item defines the maximum number
of bytes the send queue of a client is allowed to grow to. The item
influences the "send buffer overrun error condition". For packet oriented
protocols (UDP and ICMP) you need to specify at least the maximum number
of bytes a single packets can have. For UDP and ICMP this is 64 KByte.
The value specified here is an initial value. It is used unless the
server bound to this port changes it.
recv-buffer-size (integer)
recv-buffer-size
configuration item defines the maximum
number of bytes the receive queue of a client is allowed to grow to.
The item influences the "receive buffer underrun error condition". The
value specified here is an initial value. It is used unless the server
bound to this port changes it.
connect-frequency (integer)
allow (list of strings)
allow
and deny
lists are lists of IP addresses in
dotted decimal form (e.g. `192.168.2.1'). The allow
list defines
the remote machines which are allowed to connect to the port. It applies
to TCP ports.
deny (list of strings)
deny
list defines the remote machines which are not allowed to
connect to the port. Each connection from one of these IP addresses will
be refused and shut down immediately. It applies to TCP ports.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(define-port! 'foo-tcp-port '( ;; usual settings (proto . tcp) ;; protocol is tcp (port . 42421) ;; network port 42421 (ipaddr . *) ;; bind to all known interfaces (device . eth0) ;; bind to network card ;; enhanced settings (backlog . 5) ;; enqueue max. 5 connections (connect-frequency . 1) ;; allow 1 connect per second (send-buffer-size . 1024) ;; initial send buffer size in bytes (recv-buffer-size . 1024) ;; initial receive buffer size in bytes ;; allow connections from these ip addresses (allow . (127.0.0.1 127.0.0.2)) ;; refuse connections from this ip address (deny . (192.168.2.7)) )) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The only mandatory item is the file name of each pipe. If you want to specify a user creating the named pipe (file ownership) use either the user or the uid setting. Same goes for the items group and gid.
(define-port! 'foo-pipe-port `( (proto . pipe) ;; protocol is named pipe ;; specify the receiving endpoint (recv . ((name . ".foo-recv") ;; name of the pipe (permissions . #o0666) ;; create it with these permissions (user . "calvin") ;; as user "calvin" (uid . 50) ;; with the user id 50 (group . "heros") ;; which is in the group "heros" (gid . 100))) ;; with the group id 100 ;; specify the sending endpoint (send . ((name . ".foo-send") (permissions . #o0666) (user . "hobbes") (uid . 51) (group . "stuffed") (gid . 101))) )) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(define-port! 'foo-icmp-port '((proto . icmp) (ipaddr . 127.0.0.1) (type . 8))) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(define-port! 'foo-udp-port `((proto . udp) (port . 27952))) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A server
(in Serveez) is a snippet of code that implements some
protocol. There are many servers built into Serveez but you can implement
your own, too. For example we provide a webserver implementing the
Hypertext Transfer Protocol (HTTP). Each server has a different set of
options you can change. You can have many instances of every server, each
with a different set of options. For example: You can create a webserver
on TCP port 42420 publishing the Serveez documentation and also have another
webserver on a different port publishing something else. Every server
has a unique name you assign to it. The name of the server is later used
to bind it to a port.
The following example instantiates a server with the short name "foo". Each
server in Serveez has got a short name. See section 4.4 Existing servers, for the
details. This example demonstrates everything which is possible in server
configurations. You start a definition of a server with the guile function
(define-server!)
. The following argument specifies the name of the
server instance (in this case "foo-server") which starts with the short
name. The second argument describes the server in detail. Each
configuration item is setup with a (key . value)
pair where "key" is
the name of the configuration item and "value" is the value which depends
on the type of the item. See section 4.3 Some words about server configuration, for a detailed
description of each type of value.
(define-server! 'foo-server '( (bar . 100) ;; number (reply . "Booo") ;; character string (messages . ;; list of strings ("Welcome to the foo test server." "This one echos your lines.")) (ports . (5 6 7 8 9)) ;; list of numbers (port . foo-tcp-port) ;; a port configuration (assoc . (( "GNU" . "great" ) ;; associative list ( "Tree" . "tall" ))) (truth . #f) ;; boolean value )) |
Serveez provides a number of server types. Each of them has a short name. The name of the server instance has to begin with this short name followed by a dash (-). You can append any suffix then. In the example above "foo" is the short name and "foo-server" the name of the server instance.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Finally you can bind servers to ports. When you do so the server you created listens on the port, accepts connections and serves clients. It does so as soon as Serveez enters its main loop right after running the configuration file. Serveez won't stop until you interrupt it (e.g. by pressing ^C in the terminal you started it in).
This example binds the server "foo-server" (s.a.) to the port "foo-tcp-port"
which was described above. Therefore you need to call the guile function
(bind-server!)
which takes two arguments specifying the name of a port
configuration and a server instance. Both need to be defined before
you can write this statement.
(bind-server! 'foo-tcp-port 'foo-server) |
One of the main features of Serveez is that you can bind multiple servers to the same port. This for example is useful to pass braindead firewall configurations or proxy servers. It is also possible to bind servers to ports they are actually not designed for. This might be used for debugging servers or other funny things (again, think about the firewall). This is the point we have to warn you: Some protocols cannot share the same port (e.g. the tunnel server) and some protocols simply won't work on 'wrong' ports. Additionally, you will not get error messages when that happens. The server just will not work then.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The three functions (define-port!)
, (define-server!)
and
(bind-server!)
return #t
on success and #f
on failure.
For your convenience we provide some more Guile functions. Some of these
are based upon the above. You will find the additional functions in the
file `serveez.scm'. In order to include this convenience
functionality you can (primitive-load "serveez.scm")
at the top
of the configuration file.
(interface-add! . interface)
(loadpath-add! . path)
(bind-servers! . args)
(bind-server!)
. It takes a list of port
configurations and servers and binds each to another.
(bind-tcp-port-range! from to . servers)
(bind-udp-port-range! from to . servers)
(serveez-verbosity verbosity)
(serveez-maxsockets max)
(serveez-passwd password)
We now have a closer look at the internals of Serveez. If you are not interested in that have a look at the existing servers (See section 4.4 Existing servers.).
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |