XCOMPUTE-SERVER

Access Control

To connect for the first time, team members email their fingerprint to the desired XCOMPUTE-SERVER admin, who can then add entries to users.cfg defining guest and/or user access, like so:

allow_guests=false
XCGENERATEDRSAFINGERPRINTABCDEFG1234=person@mycompany.com
ANOTHERXCGENERATEDFINGERPRINT6789XYZ=someone@somewhere.com
SECONDARYCOMPUTERFORTHESAMEPERSONRSA=someone@somewhere.com
...

If allow_guests=true, anyone with an authenticated XCOMPUTE-CLIENT session can connect to your server host, assuming they know the address and port number. If connected, their name will appear as guest_$signature. Router LAN/WAN settings dictate the visibility of the localnet to the public internet (usually by enabling port forwarding to the server of interest).

Additional Notes:

Configs are loaded at application launch but some can be re-loaded during runtime by issuing a special xcompute runtime command load users.cfg. Similarly, the compute config can be updated at runtime from a wire message or via load compute.cfg.

An email and fingerprint are never transmit over an unsecure network, but rather, a hashed $signature is used to identify potential connections in an initial transmission.

Execution

System-managed service

XCOMPUTE-SERVER can be managed as a service that starts or restarts when the host system boots up, and is shut down when the system is shut down, similar to Apache2 and other persistent host services.

For Ubuntu and Debian systems, the Debian (.deb) package in recommended. Like other Debian packages, adminstrator (root) privilege is required for installation. A new user xcompute is created to run XCOMPUTE-SERVER and manage team projects files. Following setup and restart, the service is managed by Linux systemd.

Check the systemd service status:

systemctl status xcompute

If the service is not running, start it:

sudo systemctl start xcompute

The service can also be stopped:

sudo systemctl stop xcompute

While other Linux packaging systems (e.g., RPM) are not support, management as a service by systemd may still be possible by exploiting the tarball (.tar.xz) file that is normally provided for user-managed service. As with other system services, it requires adminstrator (root) privilege and is only recommended when the host system’s support staff has extensive Linux experience. This will need to be in consultation with Xplicit Computing staff.

User-managed service

XCOMPUTE-SERVER can be run manually as an individual user application. No adminstrator (root) privilege is required as the software is installed in a user-owned directory. XCOMPUTE-SERVER runs as process owned by the user, and thus all data files consumed or generated by XCOMPUTE-SERVER are under control of the user. This is most suitable for individual use and where root privilege is not readily available.

Navigate to the executable working directory and start an interactive session:

./xcompute-server

Ensure the listening socket has been bound and at least one OpenCL device is available. Only one xcompute-server instance is permitted, so don’t attempt to run as a user if a systemd xcompute service is also running.

Batch mode

It is also possible to execute a non-interactive “batch” session to process files without binding a socket, like so:

./xcompute-server --batch some_file.stl

The default configuration will (always) come from compute.cfg.

File I/O

Client interfaces import/export external files to/from the server, while the server host saves/loads native XC files locally:

	Input	Output
Server	Load	Save
Client	Import	Export

Save & Load

XCOMPUTE-SERVER saves the project state to the output directory and loads from the input directory, all on the host machine. The project input/output directories should be specified in server.cfg, such as a fast SSD:

input=/path/to/project/
output=/path/to/project/

Project files are organized in a filesystem hierarchy with the definition and supporting files for each system within each folder. (In this manner, each system effectively maps to a folder.) A mixture of external and native formats can be present, with XC files accesssible with XC-Messages:

*.xcs - system setup
*.xcg - geometry
*.xco - data

By convention, each data property is saved to an *.xco file, which provides performant high-density storage and access. For convenience, a standalone app xc2csv is provided to view data files in a spreadsheet format.

Import & Export

XCOMPUTE-SERVER can import files locally (for testing or received from XCOMPUTE-CLIENT), including the following formats:

stl, obj, msh, sdf

XCOMPUTE-SERVER can also export files locally (for testing or to send to XCOMPUTE-CLIENT), including the following formats:

csv, vtu, stl, obj, msh, sdf

The default export types for geometries and systems can be defined in compute.cfg, such as the defaults:

SystemExportType=vtu
GeometryExportType=msh