Files
factorio-clusterio/packages/controller
Hornwitser bcd94709d2 Refactor link system to JSON serialisable class pattern
Reverse the direction of the API for sending messages from

    messageDefinition.send(link, { content });

to

    link.send(new MessageClass(content));

and convert all message definitions to use the JSON serialisable class
pattern and explicit registration of message handlers, along with a
end-to-end based routing of messages instead of link to link.

The experience I gained from the existing way messages were defined and
sent over links was that it was difficult to understand for people
unfamiliar with the system.  The automatic registration of message
handlers ment that code was being called as if by magic from nowhere
with no easy way to discover it.  The manual forwarding and rules for
what can be sent where and how obscured its working.

The use of pure JSON as both input and output from message handlers made
it tedious to work with.  Data had to be manually converted between the
program representation and the over the wire format, which made handler
code unplesant to write.  Particularly because the over the wire format
used snake_case while the program code uses camelCase for variables.
The idea behind the decision to do it this way was to make it more clear
which data came from the wire and which from the program, and while this
worked it didn't make message handlers any nicer to write.

The direction of the API and magic registration of message handlers also
meant that a future migration to TypeScript would be troublesome.  While
it may be possible to implement, the degree of TypeScript magic required
would go starkly against the principle of keep it simple stupid.

By refactoring to using the JSON serialisable class pattern most of
these issues go away.  There is no longer a need to distinguish the on
wire format of messages with the program representation because the only
place that deals with the wire format of messages are the toJSON and
fromJSON methods on the classes themselves.  Message handlers will work
with proper instances of classes instead of raw data, something that
makes them easier to write, and trivial to type with TypeScript.

End-to-end routing also simplifies sending messages that need to do
mulitple hops to reach the destination.  And removes the need for having
all messages be specified in plugin's info module, as they can be routed
without having to be parsed completely.

The explicit registration of message handlers is something that I
thought would be tedious boilerplate code that could be automated away.
But experience now shows it to be the opposite.  Allthough dull
repetition, the purpose it serves is to link together the code in a way
that humans can easily find.  With explicit registration searching the
name of the message handler in the editor will show the registration that
ties it together with the type of message it handles and the kind of
registration.  With implicit registration searching the name of the
message handler turns up only the handler with no clue as to what calls
it.
2023-04-23 13:19:46 +02:00
..
2023-02-22 15:30:51 +01:00
2023-02-22 15:30:51 +01:00
2023-02-22 15:30:51 +01:00
2023-02-22 15:30:51 +01:00
2023-02-22 15:30:51 +01:00

Clusterio Controller

Communication hub for Clusterio clusters. The controller forwards data between Clusterio hosts connected to it and allows the cluster to be remotely managed through WebSocket connections to it either by using the included web interface or the Clusterio ctl command line utility.

Usage

npx clusteriocontroller <command>

Common options:

  • --plugin-list <file> JSON file to use for storing the list of plugins that are available to the controller. Defaults to plugin-list.json and will be created if it does not exist. See the plugin command for managing this list.

  • --config <file> JSON file to use for storing configuration for the controller. Defaults to config-controller.json and will be created if it does not exist. See the config command for inspecting and modifying the configuration.

plugin <command>

Configure plugins available to be loaded by the controller. The available plugins will be loaded unless they have been disabled in the configuration, see the config command for disabling plugins.

plugin add <path>

Add plugin either by require path or relative/absolute path to the plugin directory. A relative path must start with ./ or ../ (or .\ and ..\ on Windows) otherwise it will be assumed to be a require path for an installed package in node_modules.

For example, installing the Subspace Storage plugin:

npm install @clusterio/plugin-subspace_storage
npx clusteriocontroller plugin add @clusterio/plugin-subspace_storage

Since the plugin-list.json is shared between controller, host and ctl you usually only need to do this once per machine.

plugin remove <name>

Remove a plugin by its name. This should be done before uninstalling the plugin, otherwise there will be an error when Clusterio tries to load the info from the plugin. Removing and unistalling a plugin is usually not neccessary as the functions provided by the plugin can be disabled in the config.

For example, uninstalling the Subspace Storage plugin:

npx clusteriocontroller plugin remove subspace_storage
npm uninstall @clusterio/plugin-subspace_storage

Since the plugin-list.json is shared between controller, host and ctl you usually only need to do this once per machine.

plugin list

Lists the plugins set up to be available by name followed by path.

config

Manage the controller configuration offline. This should only be used when the controller is stopped, otherwise the config read might be out of date and config changes will be overwritten when the controller shuts down.

config set <config-entry> [value]

Set a config entry to the given value. If value is not provided the entry is set to null. If the config entry is of type object the value must be a valid JSON serialization of an object.

See docs/configuration.md in the main repositiory for the available configuration entries.

config show <config-entry>

Shows the value for a single config entry.

config list

Lists up all configuration entries with their currently configured values.

bootstrap

Commands for setting up initial admin acount and access to the cluster.

bootstrap create-admin <name>

Creates a new user account with the given name if it does not already exist in the cluster and grant it full cluster admin permission. You should be using your own Factorio multiplayer username here.

bootstrap generate-user-token <name>

Generate an access token for logging in and possibly managing the cluster from the given user account. This can be used both in the web interface and as the controller_token to connect with clusterioctl.

bootstrap create-ctl-config <name>

Creates a clusterioctl config for the given user with url and token set up for connecting to the cluster.

run

Runs the controller.

See Also

The Clusterio repository for instructions on how to set up a cluster.