Skip to main content

Client/Server Architecture

RunScore splits into two programs — RSServer and RSClient — so multiple computers can work the same race at once. The server stores all data. Each client connects over the network to view and edit that data.

Two databases, one server​

RunScore keeps two kinds of data:

DatabaseStorageDescription
Participant databaseentries.dta (flat file, one record per line)Names, ages, addresses, bib numbers. Fields that need fast lookup (bibs, names) are kept in memory.
ResultsPer-event file pairs: .fn2 (finish order) and .tm4 (times)Each event (e.g. swim, bike, run in a triathlon, or just the finish) gets its own pair.

Both live entirely on the server. Clients never store race data locally. RSClient fetches every screen from RSServer over the network and sends every edit back to the server to save.

How it works​

  1. RSServer runs stand-alone unless you set a Server TCP port in Preferences. Port 0 (the default) means the server accepts no client connections.
  2. When a non-zero port is set (valid range: 1024–65535), RSServer starts a MasterServer listener on that port at launch.
  3. RSClient connects to the server's IP address and port. The race that opens on the client is whichever race the server has open — the client does not choose its own race.
  4. All interactions — reading a record, saving an edit, adding an entry — go through TCP/IP. Nothing changes on the client's disk; the server's database is the single source of truth.
  5. The client sends a heartbeat (Ping) every 60 seconds. The server replies with the current race info. If the client detects the race has changed, it closes its current race view.
Getting started

To set up client/server, configure a TCP port in Preferences, then install RSClient on each additional machine. See Connection Troubleshooting for step-by-step verification.

Port range

Any port from 1024 to 65535 works. Pick a port above 30,000 to avoid conflicts with well-known services. Do not reuse a port already assigned to MyLaps, ChronoTrack, or other timing hardware.

Thin-client restrictions​

RSClient is deliberately limited. Some operations are blocked outright with a message; others are simply absent from the client's menus.

Hard restrictions (blocked with a user-facing message)​

What's blockedMessage
Delete listing files"RunScore client cannot delete files"
Sort results by time (Alt+T)"Sort by time can only be done from RSServer."
Sort results by bib (Alt+B)"Sort by bib can only be done from RSServer."
Clear a field for all records (F5)"Can not clear a record from a RunScore client"
Edit entries.ini"Cannot edit <file> from client."
Edit validation file"Client cannot edit <file> file."
Update All entries (Alt+F4)"Updating ALL entries can only be done from server."

Absent from client menus​

What's absentNotes
Import/export database (Files menu)Menu items not present in RSClient
Edit list of eventsNot in RSClient Misc menu
Simulate a raceNot in RSClient Misc menu
Edit Clients tableServer-only (Misc menu)
Edit Roles tableServer-only (Misc menu)

Operations controlled by roles​

These actions work on RSClient but depend on the account's role:

OperationWithout rolesWith roles
Delete a record (Browse screen)AllowedControlled by the Browse Delete permission
Send a listing file to the browserAllowedNot restricted by roles
FTP and email

RSClient can trigger FTP uploads and email sends, but the actual network operation runs on the server — the client just sends the request.

Version handshake​

When RSClient connects, the server checks whether both sides run the exact same version and build date. If the versions differ in any way, the server refuses the connection. There is no partial-match or warning mode. Both sides must run the same build.

Keep versions in sync

Copy the latest RSClient installer to every client machine whenever you update the server. Even a patch-level difference (e.g. 9.0.1 vs. 9.0.3) will block the connection.

See also​