Resourcerver - *nix Resource Server

Purpose of this Project.

Resourcerver is a *nix ("Unix^®-like operating systems" such as Linux and FreeBSD) framework for large, multi-process applications. Resourcerver is intended to help developers create large applications using several smaller, special-purpose programs by controlling their run-time structures and by facilitating control-oriented IPC between the special-purpose components.

Resourcerver is intended to be the permeating structural entity of an application designed to utilize it. Resourcerver functions by providing a daemonized server process for each instance of each application. All of the application's components are connected to that server and communicate with each other through it. This communication is regulated by the server to bring stability to the application as a whole, thereby increasing its reliability. Communication regulation is based on a role-based model where each of the application's processes has a discrete category within the context of the Resourcerver system. These categories define the fundamental requirements of how each process can interact with the system.

Applications built around Resourcerver will generally use programs with discretely-defined functionality. Ideally, an application will use separate programs to manage data retrieval, data processing, network connections, and user control over the application. The Resourcerver system will assemble these programs as a set of processes attached to a single server based on a configuration specified at run-time, allowing for dynamic application instances.

The individual programs used in an application can be written by the application's developer in either C or C++ using the Resourcerver API. The API provides a simple C interface between the running program and the Resourcerver libraries. The Resourcerver libraries manage all communication with the server based on the actions taken by the running program. Communication with other processes is routed through the server for security and "sanity" filtering.

The main purpose of the server in a Resourcerver application is to bind third-party programs into a dynamic system to form an application. Incidentally, it must facilitate IPC while exercising security control over the application. Most of the application's processes will be created by the server itself so that it can control the process' user and group IDs (super-user applications can use multiple users and groups,) which the server strictly regulates.

The primary benefit of creating an application with Resourcerver is the ability to modify the structure of the application while it's running. This allows the application to be assembled in a series of steps, allows isolation and correction of run-time errors, allows different instances of the application to have different structures, and lastly allows the application to be shut down incrementally.

The core Resourcerver package includes IPC-forwarding programs that allow an application to relocate processes across network connections. These IPC forwarders allow run-time specification of security-filter plug-ins that provide address filtering, connection authentication, and transmission encryption. The core package includes filters for SRP authentication and TLS encryption, as well as user-space incoming-IP filtering.

The Resourcerver IPC system is fully extensible. The core package includes and utilized several standardized extensions that can be used as examples for third-party extensions. The inner workings and other pertinent information about the IPC system are discussed in detail in the project's documentation (see the links below.)

Recent Project News.

August 18^th, 2009: I made several very important changes with this update, the most significant of which is the addition of a TLS encryption and authentication security filter for IPC forwarders. This allows secure connections between forwarders not previously possible. With this came the permanent removal of the encode/decode functions in the security filter API; encryption is now handled entirely by the send/receive functions. Combined with a kernel-space firewall and the address-filtering security filters, this new filter allows for very secure Resourcerver systems. I also added readline support to several programs, making it much easier to reuse commands when working with the interactive Resourcerver tools.

February 20^th, 2009: Permanently migrated project hosting from SourceForge.net to BerliOS.de.

February 16^th, 2009: Added a subversion repository mirror for public access. The link given can be used with svn command-line client, or you can browse the source and changes directly from the web. I'd tracked changes with CVS for quite a while; however, the structure changed too often for me to keep up. Version control restarts from just after the last beta release. Formal releases will carry the "gamma" designator, but should still be considered beta releases. The mirror repository is a copy of the repository on my development machine. I only plan to synchronize the mirror when the code compiles and runs; not between those times.

December 22^nd, 2008: Added a network security filter to temporarily deny attempted reconnections by hosts disconnected for errors. This filter is a socket-forwarder plug-in intended to mitigate the effects of port scanners. After disconnecting a host for sending bad data, etc., the forwarder will notify the filter, which will tabulate the host's address. The filter will deny incoming connections from that host for a period of time specified when the filter is loaded, preventing performance degradation caused by unfriendly programs.

December 20^th, 2008: First successful high-intensity network test. This required quite a bit of tuning to get it to work properly and with reproducible results. This test was performed by sending a "ping server" message from a client to the server on a remote machine 1024 times within about 3 seconds. This caused severe problems initially, but after about 10 hours of troubleshooting and with the addition of message-queue pausing I got it to reliably respond to all effective ping messages (some were discarded by the server as a self-protection measure to prevent a crash due to a backlog at the forwarder.)

December 16^th, 2008: Completion of the first successful wide-area-network (WAN) test between Resourcerver systems. This involved two machines: one with a static IP address on a controlled network and one with a dynamic wireless IP address. The machine with the static IP listened to a port and the other connected. I proceeded to poll the wireless-IP server for registered Resourcerver services from the static-IP server, and succeeded in having the wireless-IP server automatically register a remote service with the static-IP server. Upon disconnecting the wireless-IP server, the static-IP server registered the loss of connection with no human-visible delay. While I've performed a substantial number of local-machine network tests, this was the first test between two separate machines.

December 8^th, 2008: Addition of a "respawn" client. This client will monitor other clients (specified with a configuration file) and if they disconnect for any reason (e.g. crash or are killed,) this client will restart them. The respawn client is a very powerful addition to the system because it allows "self-healing" applications, which can be especially useful for remote systems.

November 29^th, 2008: Addition of command substitution in configuration files. While the sematics are very limited, this provides a very powerful interface between the shell and the configuration stage of the server (and some client programs.)

November 1^st, 2008: Release of the first beta version. This version contains several improvements over the last alpha version. This release marks a significant shift toward the eventual prototyping of ideal implementation methods, which will be the major focus of the beta versions. The secondary focus will be on securing super-user server instances. This release comes with a refined emphasis of purpose as a structural framework instead of merely an IPC infrastructure. Future project efforts will follow this refined philosophy.

August 7^th, 2008: Release of the first fully-functional example application. This application is a very simple simulation of a home automation system. Development of this example resulted in quite a few project improvements.

April 13^th, 2008: The initial versions of the project's documentation are complete. I'm performing final checks before posting the initial release. Update: Initial release posted the same day.

February 24^th, 2008: Posted the first version of this front page. I'm currently working on the API reference and rewriting the guides (composting the working guides.) The first release should be out around the beginning of summer 2008.

February 18^th, 2008: The core Resourcerver package is complete and awaiting documentation. Initial release won't happen before at least the user's and application developer's guides are complete. The initial API documentation is nearly complete.

Project Resources.

• Resourcerver Download Site.  [subversion]  [browse source]
  The official download site for the Resourcerver Project.
  
  
• Resourcerver User's Guide.
  An in-depth guide for programmers and non-programmers.
  
  
• Resourcerver Application Development Guide.
  An introductory guide for programmers writing clients and assembling applications.
  
  
• Resourcerver C/C++ API Reference.
  A complete reference of the Resourcerver C/C++ API.
  
  
• Resourcerver Command Plug-in Development Guide.
  An (unfinished) in-depth guide for programmers writing command plug-ins.
  
  
• Resourcerver Security Plug-in Development Guide.
  An (unfinished) in-depth guide for programmers writing network security filter plug-ins.
  

Resourcerver Terms of Use.

Acknowledgements and "Thanks".

I'll list your name, project, or organization here if you provide a significant contribution to the Resourcerver Project. I'll ask before listing any individual person or private project/organization in case you don't want to be known publicly. I can't list everyone here; therefore, I'll only list those who've expended a generous amount of time or effort, so as to not trivialize major contributions.

Code Contributions, Bug Fixes, and Quality Improvements.

Development Tools.

General.