First draft

[Baptouuuu]

This PR lay the ground structure of this package. It doesn't simulate every part of the operating system, so far it covers the clock, HTTP requests and processes. The rest will be done in other PRs to keep each as small as possible.

It started as just a way to configure an OperatingSystem object but it quickly became messy when dealing with representing multiple remote machines. For example contacting a same machine over HTTP and then SSH was hard to represent as it requires to have the same persistent OS object (to share the same state).

That's why the current design models these concepts:

• a Machine
• a Cluster to represent a collection of Machines that can talk to each other

These public structures are immutable to ease configuring them. Then they are booted, meaning it creates mutable copies of these objects. Once booted they are connected over a Network object to allow to route HTTP requests and SSH connections.

The Network also starts a NTPServer that allows to centralise the time between machines. When connections are made over this network it can inject latencies by fast forwarding the NTPServer internal clock.

A Machine clock is bound to the NTPServer one but when accessing the clock time it can drift from the central clock (either by speeding up or slowing down). This drift is reseted when the machine makes any call over the network in order to simulate a real machine synchronising over an NTP server.

When a Machine process tries to halt itself, instead of really waiting for the specified period it jumps the central clock by this period.

The latencies and drifts are represented as ring buffers instead of continuous sequence of random values to allow to decouple BlackBox from this package. Also this helps keep this simulation deterministic. But the way it's represented allows to still introduce such behaviour later on without a BC break.

The overall time can also be sped up (meaning the app is slower than actual behaviour) to simulate degraded performance in a cluster. For now it's specified as a factor between 2 and 10, this range is arbitrary and may change in the future.

The cluster can also be specified any start point in time to allow to test in the past or future. Each machine OS is configurable meaning each machine can be specified to operate on a different timezone. This allows to test any deployment topology.

Each Machine can be injected a HTTP or CLI app, this corresponds to the 2 cases covered by innmind/framework.

Note

The remaining todos are either decisions that can be made later on (needs more feedback before making a decision) or requires to use other packages that rely on innmind/foundation. This last point will wait for the next major version of innmind/foundation before implementing them.