robust-services-core

This repository contains

1. A framework for developing robust applications in C++.
2. An application built using the framework.
3. Tools for the static analysis of C++ software.
4. A framework for developing a bot that can play the board game Diplomacy.

Robust Services Core

The framework for robust C++ applications is referred to as the Robust
Services Core (RSC). RSC will put your project on the right path and jump-start
it if you’re developing or reengineering a system whose requirements can be
characterized as

• highly available, reliable, and/or scalable;
• embedded, reactive, stateful, and/or distributed.

The design patterns used in RSC make developers more productive. They have
been proven in flagship telecom products, including (from the author’s
experience as its chief software architect) the core network server that
handles all of the calls in AT&T’s cellular network. A pattern language that
summarizes the patterns appears in the
second chapter of Robust Communications Software.
The document RSC Software Overview
describes which of them are currently available in this repository and points
to the primary code files that implement them, and this
tutorial provides more information about some of
them.

C++ static analysis tools

The development of RSC has been somewhat sidetracked by the development of C++
static analysis tools. These tools detect violations of various C++ design
guidelines, such as those found in Scott Meyers’ Effective C++. They also
analyze #include directives to determine which ones to add or delete. Their
editor then allows you to easily and interactively fix many of the warnings
that the tool generates. Even if you’re not developing applications with
RSC, you might find these tools useful. An overview of them is provided
here.

POTS application

Including an application with a framework serves to test it and illustrate its
use. This repository therefore includes a POTS (Plain Ordinary Telephone
Service) application. POTS was chosen for several reasons. For one thing, the
author had extensive experience with similar applications while working in the
telecom industry. But more importantly, POTS is a non-trivial application, yet
everyone has a reasonable understanding of what it does. You should therefore
be able to figure out what the POTS code is doing without reading a large
specification. An overview of the POTS application is provided
here.

Diplomacy AI client

In 2002, a group in the UK began to design a protocol that allows software
bots to play the board game
Diplomacy). Their
website has various useful links and downloads,
amongst which is the executable for a Diplomacy server. Bots log into this
server, which sends them the state of the game, allows them to communicate with
one another using the protocol, and adjudicates the moves that they submit.
Their website also provides software for developing bots. I decided to
refactor this software, decouple it from
Windows, and bring it more in line with C++11. This helped RSC evolve
to better support standalone clients that use IP (TCP, in this case). The
resulting software is available in the dip directory and is
described in some further detail here.

Documentation

This page provides an overview of RSC. Another page lists
documents that go into far more depth on many topics.

Installing the repository

Download one of the
releases.
Code committed since the latest release is work in progress and may be unstable
or incomplete, so downloading from the Code▾ dropdown menu on the
main page is not recommended.

Warning

For proper operation, RSC must be launched from a directory below
its src directory. See the installation guide.

Building an executable

RSC

• requires C++17;
• is a console application;
• runs on both Windows and Linux;
• defines an abstraction layer, in the form of generic C++ .h‘s and
  platform-specific .cpp‘s, that should allow it to be ported to other systems
  fairly easily.

If you don’t want to build RSC, debug and release
executables are provided with each release.

The directories that contain RSC’s source code, and the dependencies between
them, are listed in the comments that precede the implementation of
main. Each of these directories is built as a separate
static library, with main residing in its own directory.

RSC is developed using Visual Studio 2022 and built using CMake, as described
here. Windows build options for RSC
are described here. Visual
Studio’s .vcxproj files are no longer used during builds, so
they were removed from the repository.

Running the executable

During initialization, RSC displays each module as it is initialized.
(A module is equivalent to a static library.) After all modules
have initialized, the CLI prompt nb> appears to indicate that CLI commands
in the nb directory are available. What is written to the console
during startup is shown here, and a list of all
CLI commands is provided here.

If you enter >read saveinit as the first CLI command, a function trace of
the initialization, which starts even before the invocation of main, is
generated. This trace will look a lot like this.
Each function that appears in such a trace invoked Debug::ft, which records
the following:

• the function’s name
• the time when it was invoked
• the thread that invoked it
• its depth (in frames) on the stack: this controls indentation so that you
  can see how function calls were nested
• the total time spent in the function (in microseconds)
• the net time spent in the function (in microseconds)

All output appears in the directory ../