Simula Research Laboratory / Center for Resilient Networks and Applications / NorNet
Homepage of Thomas Dreibholz / Thomas Dreibholz's Reliable Server Pooling (RSerPool) Page


Welcome to Thomas Dreibholz's
Reliable Server Pooling (RSerPool) Page
The RSPLIB Project
The RSPLIB Project


📑 Quick Navigation


📰 Latest News


💡 What is Reliable Server Pooling (RSerPool)?

Introduction

The development and standardisation of an application-independent server pooling architecture has been set as the goal of the IETF RSerPool WG. As a result, the working group has created their concept Reliable Server Pooling, abbreviated as RSerPool, which at the moment consists of eight RFCs, several Internet Drafts and RSPLIB as reference implementation.

Requirements to the Reliable Server Pooling Architecture

As key requirements to the Reliable Server Pooling architecture, the following points has been identified in RFC 3237:

The Reliable Server Pooling Architecture

Figure of the RSerPool Protocol Stack
An RSerPool Scenario

The figure above shows the building blocks of the RSerPool architecture, which has been defined by the IETF RSerPool WG in RFC 5351:. In the terminology of RSerPool a server is denoted as a Pool Element (PE). In its Pool, it is identified by its Pool Element Identifier (PE ID), a 32-bit number. The PE ID is randomly chosen upon a PE’s registration to its pool. The set of all pools is denoted as the Handlespace. In older literature, it may be denoted as Namespace. This denomination has been dropped in order to avoid confusion with the Domain Name System (DNS). Each pool in a handlespace is identified by a unique Pool Handle (PH), which is represented by an arbitrary byte vector. Usually, this is an ASCII or Unicode representation of the pool, e.g. “Compute Pool” or “Web Server Pool”.

Figure of the RSerPool Protocol Stack
A Handlespace Example

Each handlespace has a certain scope (e.g. an organization or company), which is denoted as Operation Scope. It is an explicit non-goal of RSerPool to manage the global Internet’s pools within a single handlespace. Due to the limitation of operation scopes, it is possible to keep the handlespace “flat”. That is, PHs do not have any hierarchy in contrast to the DNS with its top-level and sub-domains. This constraint results in a significant simplification of the handlespace management.

Within an operation scope, the handlespace is managed by redundant Registrars. In literature, this component is also denoted as ENRP Server or Name Server. Since “registrar” is the most expressive term, this denotation is used here. PRs have to be redundant in order to avoid a PR to become a single point of failure (SPoF). Each PR of an operation scope is identified by its Registrar ID (PR ID), which is a 32-bit random number. It is not necessary to ensure uniqueness of PR IDs. A PR contains a complete copy of the operation scope’s handlespace. PRs of an operation scope synchronize their view of the handlespace using the Endpoint HaNdlespace Redundancy Protocol (ENRP) defined in RFC 5353. Older versions of this protocol use the term Endpoint Namespace Redundancy Protocol; this naming has been replaced to avoid confusion with DNS, but the abbreviation has been kept. Due to handlespace synchronization by ENRP, PRs of an operation scope are functionally equal. That is, if any of the PRs fails, each other PR is able to seamlessly replace it.

By using the Aggregate Server Access Protocol (ASAP), defined in RFC 5352, a PE can add itself to a pool or remove it from by requesting a registration or deregistration from an arbitrary PR of the operation scope. In case of successful registration, the PR chosen for registration becomes the PE’s Home-PR (PR-H). A PR-H not only informs the other PRs of the operation scope about the registration or deregistration of its PEs, it also monitors the availability of its PEs by ASAP Keep-Alive messages. A keep-alive message by a PR-H has to be acknowledged by the PE within a certain time interval. If the PE fails to answer within a certain timeout, it is assumed to be dead and immediately removed from the handlespace. Furthermore, a PE is expected to re-register regularly. At a re-registration, it is also possible for the PE to change its list of transport addresses or its policy information (to be explained later).

To use the service of a pool, a client – called Pool User (PU) in RSerPool terminology – first has to request the resolution of the pool’s PH to a list of PE identities at an arbitrary PR of the operation scope. This selection procedure is denoted as Handle Resolution. For the case that the requested pool is existing, the PR will select a list of PE identities according to the pool’s Pool Member Selection Policy, also simply denoted as Pool Policy. RFC 5356 defines some standard pool policies.

Possible pool policies are e.g. a random selection (Random) or the least-loaded PE (Least Used). While in the first case it is not necessary to have any selection information (PEs are selected randomly), it is required to maintain up-to-date load information in the second case of selecting the least-loaded PE. By using an appropriate selection policy, it is e.g. possible to equally distribute the request load onto the pool’s PEs.

After reception of a list of PE identities from a PR, a PU will write the PE information into its local cache. This cache is denoted as PU-side Cache. Out of its cache, the PU will select exactly one PE – again by applying the pool’s selection policy – and establish a connection to it by using the application’s protocol, e.g. HTTP over SCTP or TCP in case of a web server. Over this connection, the service provided by the server can be used. For the case that the establishment of the connection fails or the connection is aborted during service usage, a new PE can be selected by repeating the described selection procedure. If the information in the PU-side cache is not outdated, a PE identity may be directly selected from cache, skipping the effort of asking a PR for handle resolution. After re-establishing a connection with a new PE, the state of the application session has to be re-instantiated on the new PE. The procedure necessary for session resumption is denoted as failover procedure and is of course application-specific. For an FTP download for example, the failover procedure could mean to tell the new FTP server the file name and the last received data position. By that, the FTP server will be able to resume the download session. Since the failover procedure is highly application-dependent, it is not part of RSerPool itself, though RSerPool provides far-reaching support for the implementation of arbitrary failover schemes by its Session Layer mechanisms.

To make it possible for RSerPool components to configure automatically, PRs can announce themselves via UDP over IP multicast. These announces can be received by PEs, PUs and other PRs, allowing them to learn the list of PRs currently available in the operation scope. The advantage of using IP multicast instead of broadcast is that this mechanism will also work over routers (e.g. LANs connected via a VPN) and the announces will – for the case of e.g. a switched Ethernet – only be heard and processed by stations actually interested in this information. For the case that IP multicast is not available, it is of course possible to statically configure PR addresses.

A Migration Path for Legacy Applications

RSerPool is a completely new protocol framework. To make it possible for existing specialized or proprietary server pooling solutions to iteratively migrate to an RSerPool-based solution, it is mandatory to provide a migration path. For clients without support for RSerPool, the RSerPool concept provides the possibility of a Proxy PU (PPU). A PPU handles requests of non-RSerPool clients and provides an intermediation instance between them and the RSerPool-based server pool. From a PE’s perspective, PPUs behave like regular PUs. Similar to a PPU allowing the usage of a non-RSerPool client, it is possible to use a Proxy PE (PPE) to continue using a non-RSerPool server in an RSerPool environment.

The Protocol Stack

Figure of the RSerPool Protocol Stack
The RSerPool Protocol Stack

The figure above shows the protocol stack of PR, PE and PU. The ENRP protocol is only used for the handlespace synchronization between PRs, all communications between PE and PR (registration, re-registration, deregistration, monitoring) and PU and PR (handle resolution, failure reporting) is based on the ASAP protocol. The failover support, based on an optional Session Layer between PU and PE, is also using ASAP. In this case, the ASAP protocol data (Control Channel) is multiplexed with the application protocol’s data (Data Channel) over the same connection. By using the Session Layer functionality of ASAP, a pool can be viewed as a single, highly available server from the PU’s Application Layer perspective. Failure detection and handling is mainly handled automatically in the Session Layer, transparent for the Application Layer.

The transport protocol used for RSerPool is usually SCTP, defined in RFC 9260. The important properties of SCTP requiring its usage instead of TCP are the following:

For the transport of PR announces by ASAP and ENRP via IP multicast, UDP is used as transport protocol. The usage of SCTP is mandatory for all ENRP communication between PRs and the ASAP communication between PEs and PRs. For the ASAP communication between PU and PR and the Session Layer communication between PE and PU, it is recommended to use SCTP. However, the usage of TCP together with an adaptation layer defined in draft-ietf-rserpool-tcpmapping is possible. This adaptation layer adds functionalities like Heartbeats, message framing and protocol identification on top of a TCP connection. But nevertheless, some important advantages of SCTP are missing – especially the high immunity against flooding attacks and the multi-homing property. The only meaningful reason to use TCP is when the PU implementation cannot be equipped with an SCTP stack, e.g. when using a proprietary embedded system providing only a TCP stack.

Further Details

A detailed introduction to RSerPool, including some application scenario examples, can be found in Chapter 3 of «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture»!


📽️ Demonstration

▶️ Demo Video

Watch an RSerPool/RSPLIB demonstration video here (Xvid codec required)!

A screenshot of our fractal graphics demo application: two PEs provide a fractal graphics computation service, which is requested by two PUs.

A screenshot of our fractal graphics demo application
Click here to view in full size!

🚚 Demo VM

You want to try the demo by yourself? Get a VirtualBox VM image, and run the demo:

Instructions for using the VM images can be found in the provided README file!


😀 The Implementation RSPLIB

💡 What is RSPLIB?

Reliable Server Pooling (RSerPool) is the new IETF framework for server pool management and session failover handling. In particular, it can be used for realising highly available services and load distribution. RSPLIB is the reference implementation of RSerPool. It includes:


📦 Binary Package Installation

Please use the issue tracker at https://github.com/dreibh/rsplib/issues to report bugs and issues!

Ubuntu Linux

For ready-to-install Ubuntu Linux packages of RSPLIB, see Launchpad PPA for Thomas Dreibholz!

sudo apt-add-repository -sy ppa:dreibh/ppa sudo apt-get update sudo apt-get install rsplib

Fedora Linux

For ready-to-install Fedora Linux packages of RSPLIB, see COPR PPA for Thomas Dreibholz!

sudo dnf copr enable -y dreibh/ppa sudo dnf install rsplib

FreeBSD

For ready-to-install FreeBSD packages of RSPLIB, it is included in the ports collection, see FreeBSD ports tree index of net/rsplib/!

sudo pkg install rsplib

Alternatively, to compile it from the ports sources:

cd /usr/ports/net/rsplib make sudo make install

💾 Build from Sources

RSPLIB is released under the GNU General Public Licence (GPL).

Please use the issue tracker at https://github.com/dreibh/rsplib/issues to report bugs and issues!

Development Version

The Git repository of the RSPLIB sources can be found at https://github.com/dreibh/rsplib:

git clone https://github.com/dreibh/rsplib cd rsplib sudo ci/get-dependencies --install cmake . make

Note: The script ci/get-dependencies automatically installs the build dependencies under Debian/Ubuntu Linux, Fedora Linux, and FreeBSD. For manual handling of the build dependencies, see the packaging configuration in debian/control (Debian/Ubuntu Linux), rsplib.spec (Fedora Linux), and Makefile FreeBSD.

Contributions:

Current Stable Release

The tarball has been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Its authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rsplib-<VERSION>.tar.xz.asc rsplib-<VERSION>.tar.xz 

If you do not want to use kernel SCTP, you also need our userland SCTP implementation sctplib/socketapi. The latest versions can be found at sctplib and socketapi – The User-Space SCTP Library (sctplib) and Socket API Library (socketapi). If you are unsure, just use kernel SCTP. See the handbook for details!

Old Releases

The tarballs have been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Their authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rsplib-<VERSION>.tar.xz.asc rsplib-<VERSION>.tar.xz 

🗃️ First Steps

Ensure that multicast is working!

You need a configured network interface with:

In a typical network setup, this should already be configured.

Ensure that your firewall settings allow UDP packets to/from the registrar (ASAP Announce/ENRP Presence), as well as ASAP/ENRP traffic over SCTP.

Start at least one registrar

rspregistrar

See Registrar for registrar parameters.

Start at least one pool element

rspserver -echo

You can start multiple pool elements; they may also run on different hosts, of course. If it complains about finding no registrar, check the multicast settings!

Start a pool user

rspterminal

If it complains about finding no registrar, check the multicast settings! Now, you have to manually enter some text lines on standard input.

Testing a failover

If everything works, you can test RSerPool functionality by stopping the pool element and watching the failover.

Monitor the component status

You can monitor the status of each component using the Component Status Protocol monitor cspmonitor. Simply start it by cspmonitor. It will listen for status messages sent via UDP on port 2960. The components (rspregistrar, rspserver, etc.) accept the command line arguments -cspserver=<server>:<port> and -cspinterval=<milliseconds>. For example, if you want a status update every 300 ms and your CSP client is listening on port 2960 of host 192.168.11.22, use the arguments

... -cspserver=192.168.11.22:2960 -cspinterval=300

Note: You must specify address and interval, otherwise no messages are sent.

Run Wireshark

You can use Wireshark to observe the RSerPool and demo protocol traffic. Coloring rules and filters can be found in the directory rsplib/src/wireshark. Simply copy colorfilters, dfilters and optionally preferences to $HOME/.wireshark. Dissectors for the RSerPool and application protocols are already included in recent Wireshark distributions!


📚 Pool Elements (Servers)

All example PE services can be started using the rspserver program. That is:

rspserver <OPTIONS> ...

It takes a set of common parameters as well as some service-specific arguments. These parameters are explained in the following.

The following example PE services are provided:

Notes:

Common Parameters

rspserver provides some common options for all services:

Echo Service

-echo: Selects Echo service. The default PH will be “EchoPool”.

Note: The Echo Service will be started by default, unless a different service is specified!

Example:

rspserver -echo -poolhandle=MyEchoPool

Discard Service

-discard: Selects Discard service. The default PH will be “DiscardPool”.

Example:

rspserver -discard -poolhandle=MyDiscardPool

Daytime Service

-daytime: Selects Daytime service. The default PH will be “DaytimePool”.

Example:

rspserver -daytime -poolhandle=MyDaytimePool

Character Generator Service

-chargen: Selects Character Generator service. The default PH will be “CharGenPool”.

Example:

rspserver -chargen -poolhandle=MyCharGenPool

Ping Pong Service

-pingpong: Selects Ping Pong service. The default PH will be “PingPongPool”.

The Ping Pong service provides further options:

Example:

rspserver -pingpong -poolhandle=MyPingPongPool \  -pppmaxthreads=4 -pppmaxthreads=8

Scripting Service

-scripting: Selects Scripting service. The default PH will be “ScriptingPool”.

The Scripting Service service provides further options:

Example:

rspserver -scripting -policy=LeastUsed -ssmaxthreads=4

The Scripting Service is used e.g. by the following open source tools, which provide more detailed examples:

Fractal Generator Service

-fractal: Selects the Fractal Generator service. The default PH will be “FractalGeneratorPool”.

The Fractal Generator service provides further options:

Example:

rspserver -fractal -fgpmaxthreads=4

Calculation Application Service

-calcapp: Selects the Calculation Application (CalcApp) service. The default PH will be “CalcAppPool”.

Details about the CalcApp service can be found in Chapter 8 of «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture»! The CalcApp service provides further options:

Example:

rspserver -calcapp -capcapacity=2000000 -capmaxjobs=8

📚 Pool Users (Clients)

Common Parameters

The pool users provides some common options for all programs:

Terminal Client

The PU for the Echo Service, Discard Service, Daytime Service, or Character Generator Service can be started by:

rspterminal <OPTIONS> ...

Input from standard input is sent to the PE, and the response is printed to standard output.

Example:

rspterminal -poolhandle=MyDaytimePool

Notes:

Ping Pong Client

The PU for the Ping Pong Service can be started by:

pingpongclient

The Ping Pong PU provides further options:

Example:

pingpongclient -poolhandle=MyPingPongPool -interval=333

Note: See the manpage of “pingpongclient” for further options!

man pingpongclient

Scripting Client

The PU for the Scripting Service can be started by:

scriptingclient

The Scripting PU provides further options:

To demonstrate the usage of scriptingclient, the script [scriptingserviceexample](https://github.com/dreibh/rsplib/blob/master/src/scriptingserviceexample) provides a simple example. It just takes an arbitrary ID number as parameter:

scriptingserviceexample 1234

The Scripting Service is used e.g. by the following open source tools, which provide more detailed examples:

Fractal Generator Client

The PU for the Fractal Generator Service can be started by:

fractalpooluser <OPTIONS> ...

The Fractal Generator PU provides further options:

Example (assuming the .fgp input files are installed under /usr/share/fgpconfig):

fractalpooluser \  -configdir=/usr/share/fgpconfig \  -caption="Fractal PU Demo!"

Note: See the manpage of “fractalpooluser” for further options!

man fractalpooluser

Calculation Application Client

The PU for the Calculation Application Service (CalcApp) can be started by:

calcappclient

The CalcApp PU provides further options:

Example:

calcappclient -jobinterval=30.125 -jobsize=5000000

Notes:


📚 Registrar

Start the registrar with:

rspregistrar <OPTIONS> ...

Basic Parameters

ASAP Parameters

ENRP Parameters

Further Parameters

Note: See the manpage of “rspregistrar” for further options!

man rspregistrar

📚 Component Status Protocol

The Component Status Protocol is a simple UDP-based protocol for RSerPool components to send their status to a central monitoring component. A console-based receiver is ./cspmonitor; it receives the status updates by default on UDP port 2960.

In order to send status information, the registrar as well as all servers and clients described in section B provide two parameters:

Note: Both parameters must be provided in order to send status updates!


🖋️ Citing RSPLIB in Publications

RSPLIB and related BibTeX entries can be found in AllReferences.bib!

Dreibholz, Thomas: «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture» (PDF, 9080 KiB, 267 pages, 🇬🇧), University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URN urn:nbn:de:hbz:465-20070308-164527-0, March 7, 2007.


😀 The RSerPool Demo Tool

💡 What is the RSerPool Demo Tool?

Reliable Server Pooling (RSerPool) is the new IETF framework for server pool management and session failover handling. In particular, it can be used for realising highly available services and load distribution. RSPLIB is the reference implementation of RSerPool, and RSerPool Demo Tool is a demo tool to showcase RSPLIB based on a Fractal Generator Service example. The demo tool provides an interactive GUI to start, stop, and configure RSPLIB examples, as well as to observe the status of components and their communication associations.


📦 Binary Package Installation

Please use the issue tracker at https://github.com/dreibh/rserpooldemo/issues to report bugs and issues!

Ubuntu Linux

For ready-to-install Ubuntu Linux packages of RSerPool Demo Tool, see Launchpad PPA for Thomas Dreibholz!

sudo apt-add-repository -sy ppa:dreibh/ppa sudo apt-get update sudo apt-get install rserpooldemo

Fedora Linux

For ready-to-install Fedora Linux packages of RSerPool Demo Tool, see COPR PPA for Thomas Dreibholz!

sudo dnf copr enable -y dreibh/ppa sudo dnf install rserpooldemo

FreeBSD

The RSerPool Demo Tool is still waiting for being added to the FreeBSD ports collection …


💾 Build from Sources

RSerPool Demo Tool is released under the GNU General Public Licence (GPL).

Please use the issue tracker at https://github.com/dreibh/rserpooldemo/issues to report bugs and issues!

Development Version

The Git repository of the RSerPool Demo Tool sources can be found at https://github.com/dreibh/rserpooldemo:

git clone https://github.com/dreibh/rserpooldemo cd rserpooldemo sudo ci/get-dependencies --install cmake . make

Note: The script ci/get-dependencies automatically installs the build dependencies under Debian/Ubuntu Linux, Fedora Linux, and FreeBSD. For manual handling of the build dependencies, see the packaging configuration in debian/control (Debian/Ubuntu Linux), rserpooldemo.spec (Fedora Linux), and Makefile FreeBSD.

Contributions:

Current Stable Release

The tarball has been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Its authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rserpooldemo-<VERSION>.tar.xz.asc rserpooldemo-<VERSION>.tar.xz 

Old Releases

The tarballs have been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Their authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rserpooldemo-<VERSION>.tar.xz.asc rserpooldemo-<VERSION>.tar.xz 

😀 Running the RSerPool Demo

Go to one of the demo directories, and start rserpooldemo with the corresponding demo configuration file name.

cd <PATH>/local-scenario rserpooldemo -config=local-setup.xml

Alternatively, if properly installed, a double-click on the configuration file automatically starts the demo tool.


🖋️ Citing RSerPool Demo Tool in Publications

RSerPool Demo Tool/RSPLIB and related BibTeX entries can be found in AllReferences.bib!

Dreibholz, Thomas: «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture» (PDF, 9080 KiB, 267 pages, 🇬🇧), University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URN urn:nbn:de:hbz:465-20070308-164527-0, March 7, 2007.


😀 The Simulation Model RSPSIM

💡 What is RSPSIM?

Reliable Server Pooling (RSerPool) is the new IETF framework for server pool management and session failover handling. In particular, it can be used for realising highly available services and load distribution. RSPSIM is a simulation model of RSerPool for the OMNeT++ discrete event simulator. It includes:

Details about RSPSIM and the CalcApp service can be found in «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture»!

Also take at look at Thomas Dreibholz’s Reliable Server Pooling Page for details about the real-world RSerPool implementation RSPLIB.


💾 Build from Sources

RSPSIM is released under the GNU General Public Licence (GPL).

Please use the issue tracker at https://github.com/dreibh/rspsim/issues to report bugs and issues!

Development Version

The Git repository of the RSPSIM sources can be found at https://github.com/dreibh/rspsim:

git clone https://github.com/dreibh/rspsim cd rspsim cd toolchain/tools && make && cd .. 

Contributions:

Current Stable Release

The tarball has been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Its authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rspsim-<VERSION>.tar.xz.asc rspsim-<VERSION>.tar.xz 

Old Releases

The tarballs have been signed with my GnuPG key 21412672­518D8B2D­1862EFEF­5CD5D12A­A0877B49. Their authenticity and integrity can be verified by:

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 21412672518D8B2D1862EFEF5CD5D12AA0877B49 gpg --verify rspsim-<VERSION>.tar.xz.asc rspsim-<VERSION>.tar.xz 

🗃️ First Steps

Directory Structure

How to compile and run a simple model test

cd toolchain/tools && make && cd ../.. && \ cd model && \ opp_makemake -I . -f && \ make

Notes:

After compilation, you can start the demo simulation by calling:

./model -f test1.ini

Take a look into test1.ini, the parameters should mostly be self-explaining. A detailed introduction to the model can be found in Chapter 6 of «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture»!

How to run a SimProcTC-based example?

See SimProcTC – A Simulation Processing Tool-Chain for OMNeT++ Simulations for the SimProcTC installation details. It particularly needs GNU R, bzip2 including headers, and chrpath. When it is installed, an R shell can be started in the toolchain directory:

cd toolchain R --vanilla

In the R shell, example1.R can be started:

source("example1.R")

This will parametrise the simulation defined in example1.R, perform all runs (on the local machine) and collect the results.

The plot script plot-example1.R plots the results of the example1 run.

source("plot-example1.R")

The resulting PDF file is example1.pdf.

Need more examples? Take a look into the directory example-scripts. Each <simulation>.R file is accompanied by a corresponding plot-<simulation>.R to create the corresponding PDF output. To use one of these scripts, copy it to the toolchain directory itself. They will not work in the example-scripts subdirectory!

To distribute simulation runs in a compute pool, and for more details about SimProcTC, see: SimProcTC – A Simulation Processing Tool-Chain for OMNeT++ Simulations. All examples include the file computation-pool.R, where the pool configuration has to be made!


🖋️ Citing RSPSIM in Publications

RSPSIM and related BibTeX entries can be found in AllReferences.bib!

Dreibholz, Thomas: «Reliable Server Pooling – Evaluation, Optimization and Extension of a Novel IETF Architecture» (PDF, 9080 KiB, 267 pages, 🇬🇧), University of Duisburg-Essen, Faculty of Economics, Institute for Computer Science and Business Information Systems, URN urn:nbn:de:hbz:465-20070308-164527-0, March 7, 2007.


👨‍🏫 Teaching Material

LaTeX source versions of the following teaching material are available on request. Write e-mail to Thomas Dreibholz.


📺 RSerPool/RSPLIB in the Media

October 27, 2010

Our cooperation project with Hainan University on RSerPool optimizations has been awarded with the "Scientific Research Accomplishments of Institutions of Higher Education of Hainan Province Award". A scan of the award document, including an English translation, can be found here!

November 30, 2009

I have been awarded for my work on RSerPool with the award "Wissenschaftspreis der Sparkasse Essen".

News Articles

Photos

September 26, 2008

RSerPool/RSPLIB presentation to software developers and press in Haikou, Hainan/China.

TV Report

News Articles

Photos


📖 Publications

The collected BibTeX references in a single file are available as: BiBTeX file, XML file, ODT file, DOCX file. These lists were generated using BibTeXCov 2.0!

2025

2023

2022

2021

2019

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002


📖 Standardisation

The collected BibTeX references in a single file are available as: BiBTeX file, XML file, ODT file, DOCX file. These lists were generated using BibTeXCov 2.0!

2025

2023

2019

2009

2008

2006

2005

2004

2002

If something is missing, see the Internet Draft archive at Watersprings.org. Please also contact me in case of missing or dead links.


RSerPool Introductions on Wikipedia in Different Languages

What about helping Wikipedia by adding an article in your language?

Networking and System Management Software

Simulation and Data Processing Software

Other Resources