Server

org.blockchainbench.server is the headless runner. It exercises the same engine as the desktop, but without a user interface: it loads the default configuration files, submits one group, waits for it to finish, prints a summary, and exits. It is the simplest possible client of IBlockchainBench, and a useful reference for how the engine is meant to be driven.

What it does

The bundle contributes an Eclipse application through plugin.xml whose class is SimulationApplication. Its start method is the whole program:

1. Instantiate the engine: IBlockchainBench sim = new SimulationHandler().
2. Load the default experiment CSV and the default base configuration through ConfigManager.
3. Submit them in NORMAL mode and keep the returned simulationId.
4. Poll getSimulation(id) every 500 ms until the group leaves QUEUED/RUNNING.
5. Print the final status, then walk SimulationInfo.results and print a one-line summary per SimulationRun (run id, config id, simulation time, memory used, and whether a typed result is present).
6. Call shutdown() and return EXIT_OK.

sequenceDiagram
  autonumber
  participant A as SimulationApplication
  participant CM as ConfigManager
  participant B as SimulationHandler
  A->>B: new SimulationHandler()
  A->>CM: loadCsv(DEFAULT_CSV)
  A->>CM: loadBaseConfig(DEFAULT_BASE_CONFIG_JSON)
  A->>B: submit(configs, baseConfig, NORMAL)
  B-->>A: simulationId
  loop until finished
    A->>B: getSimulation(id)
    B-->>A: SimulationInfo
    A->>A: sleep 500 ms
  end
  A->>A: print result summary
  A->>B: shutdown()

How it differs from the desktop

The server and the desktop are two clients of the same interface, distinguished only by how they wait and report.

	Server	Desktop
Interaction	none, batch	interactive JavaFX
Waiting	blocking Thread.sleep loop on the calling thread	non-blocking one-second JavaFX Timeline poll
Output	printed result summary	progress bar, status, results view
Configuration source	fixed default CSV and JSON	files chosen and edited in the UI
Mode	NORMAL	NORMAL or ATTACK, chosen in the UI

Because it blocks on the submitting thread rather than polling from a UI loop, the server is convenient for scripted or repeatable runs. Its data requirements are identical to the desktop’s — see Build and run.