BrainDraw

BrainDraw is a multi-process collaborative whiteboard built as an academic capstone project. Its client-server architecture combines a JavaFX drawing client, a whiteboard coordination server, a separate authentication data server, Java RMI command calls, and MQTT event distribution so multiple users can draw and chat on the same board.

This repository preserves the original Java 8 implementation as a portfolio artifact. It demonstrates desktop UI development, multi-process client-server design, remote method invocation, publish/subscribe messaging, local persistence, and manager/visitor collaboration workflows. It is intended for local demonstrations on a trusted machine or network—not for production or Internet-facing deployment.

Verified features

• Account registration and login through a dedicated data server.
• Manager and visitor roles within a whiteboard session.
• Named whiteboard creation, discovery, join requests, manager approval/refusal, visitor removal, and board closure.
• Collaborative freehand drawing plus line, rectangle, circle, oval, text, eraser, fill, color, and stroke-width controls.
• Canvas clear and action-history-based undo/redo controls.
• Live participant-list updates and timestamped group chat.
• Initial canvas transfer to a newly approved visitor as a targeted PNG snapshot.
• Manager-side local image open and save workflows; the UI offers PNG and GIF file choices.
• A JavaFX whiteboard-server console for connection setup, active-board listing, and event monitoring.

Architecture

BrainDraw runs as three Java processes plus an MQTT broker:

Component	Responsibility
Data server	Hosts the DB Java RMI service, registers and authenticates users, prevents duplicate concurrent logins in memory, hashes passwords, and reads/writes the local authentication file.
Whiteboard server	Hosts the Whiteboard Java RMI service, connects to the data server, keeps active boards and pending join requests in memory, enforces manager/visitor workflow decisions, starts Mosquitto, and publishes collaboration events through MQTT.
Client	Provides the JavaFX/FXML interface, sends commands to the whiteboard server over RMI, subscribes to board-specific MQTT topics through Eclipse Paho, renders incoming drawing commands, and handles local image files.
Mosquitto broker	Routes MQTT publications from the whiteboard server to subscribed clients. The original project bundles a historical Windows Mosquitto 1.5.5 distribution.

The bundled broker/runtime is retained only as part of the original academic project. It is not a recommendation for a current or security-sensitive deployment.

flowchart LR
    C1[JavaFX client] -->|RMI commands| W[Whiteboard server]
    C2[JavaFX client] -->|RMI commands| W
    W -->|RMI registration and login| D[Data server]
    D -->|salted password hashes| F[(authentication.txt)]
    W -->|Paho MQTT publish| M[Mosquitto broker]
    M -->|board topics, QoS 2| C1
    M -->|board topics, QoS 2| C2

Loading

Communication and collaboration flow

1. The data server creates an RMI registry and binds its remote service as DB.
2. The whiteboard server connects to DB, creates a second RMI registry, and binds its own service as Whiteboard.
3. The whiteboard server starts Mosquitto and connects an Eclipse Paho publisher.
4. Each client connects to the Whiteboard RMI service and to the same MQTT broker.
5. Registration, login, board lifecycle operations, drawing updates, chat submissions, and moderation commands travel from the client to the whiteboard server as RMI calls. Authentication calls are forwarded to the data server through RMI.
6. The whiteboard server converts collaboration events into board-scoped publications. Paho callbacks marshal received updates onto the JavaFX application thread for rendering.

The server uses these MQTT topics for a board named <board>:

Topic	Payload and purpose
<board>/whiteboard	JSON envelope containing a drawing command or Base64-encoded canvas snapshot, optionally targeted to one username.
<board>/message	Timestamped plain-text group-chat message.
<board>/users	Comma-separated manager and visitor list.
<board>/general	JSON join-request, board-close, and visitor-removal notifications.
<board>/join	JSON manager decision for a pending visitor.

Publications and subscriptions request MQTT QoS 2. Messages are not retained, and the Paho clients use in-memory persistence with clean sessions.

Technology stack

Area	Verified implementation
Language/runtime	Java 8; the packaged entry points use Java class-file version 52
Desktop UI	JavaFX, FXML, CSS, Canvas, and JavaFX application-thread callbacks
Request/command transport	Java RMI with separate DB and Whiteboard registries
Event transport	MQTT through Eclipse Paho Java Client 1.2.5
Broker	Historical Eclipse Mosquitto 1.5.5 Windows bundle
Message encoding	JSON-simple 1.1 plus purpose-specific string payloads
Command-line parsing	args4j 2.0.21
Logging	Log4j 1.2.17
Authentication storage	Git-ignored local runtime file containing usernames, PBKDF2-HMAC-SHA-512 password hashes, and random salts

Run locally

Prerequisites

• Windows x64 for reproducing the original packaged demo. The checked-in whiteboard server starts the historical bundled Mosquitto executable.
• A Java 8 JDK/JRE distribution that includes JavaFX. The Eclipse project targets JDK 8u202; newer Java releases are not a drop-in runtime because JavaFX was separated from the JDK and this code uses legacy Java 8 APIs.
• Three free TCP ports: one for the data-server RMI registry, one for the whiteboard-server RMI registry, and one for MQTT.

Run every command below from the nested BrainDraw application directory. The working directory matters because the security policy, storage file, broker executable, and log paths are relative.

cd BrainDraw
New-Item -ItemType Directory -Force resources/log | Out-Null
java -version

Use throwaway demo credentials only. The authentication design is appropriate for an academic local demo, not for real accounts. On first start, the data server creates storage/authentication.txt; that runtime file is ignored by Git.

1. Start the data server

In the first terminal:

java -jar resources/libraries/DataServer.jar -ip localhost -p 1111

2. Start and configure the whiteboard server

In the second terminal:

java -jar resources/libraries/WbServer.jar -ip localhost

Complete the server GUI in order:

1. Connect to the data server on port 1111. The current GUI forces this connection to localhost.
2. Start the whiteboard RMI service on a different port, for example 1331.
3. Start the MQTT broker on a third port, for example 1883.

3. Start one or more clients

In another terminal for each participant:

java -jar resources/libraries/Client.jar

In each client:

1. Enter localhost and the whiteboard-server RMI port (1331 in the example).
2. Enter the MQTT broker port (1883 in the example). The client reuses the whiteboard-server IP for MQTT.
3. Register a disposable account or log in.
4. Choose Manager to create a named board or Visitor to select an active board.
5. For a visitor, approve the join request from the manager client.

The original concise launch notes remain available in BrainDraw/readme.txt.

Compile the source

The repository does not include Maven or Gradle build configuration. With JDK 8 installed, the checked-in source compiles against the bundled dependency JARs:

cd BrainDraw
$sources = Get-ChildItem src -Recurse -Filter *.java | ForEach-Object FullName
javac -encoding UTF-8 -d bin -cp "resources/libraries/*" $sources

The existing executable JARs are fat JARs with entry points runDataServer, runWbServer, and runClient.

Screenshot recommendations

For a portfolio presentation, capture:

1. Collaborative canvas: two clients showing the same board with freehand drawing, geometric shapes, text, participant list, and chat visible.
2. Join workflow: the manager approval dialog beside the visitor's available-whiteboards screen.
3. Three-part system: the whiteboard-server monitor next to manager and visitor clients, using a clean demo board.
4. Architecture: reuse or export the architecture diagram above as supporting media.

Use localhost, fictional usernames, a neutral board name, and non-sensitive chat text. Crop terminal paths, account data, notifications, and unrelated desktop content.

Engineering scope and historical limitations

Concepts demonstrated

BrainDraw demonstrates separation of UI, coordination, and authentication responsibilities; Java RMI service boundaries; MQTT publish/subscribe event routing; JavaFX thread handoff; local credential persistence; and manager/visitor collaboration workflows. Active boards, pending joins, participant state, chat, and drawing history are intentionally in-memory rather than database-backed.

Historical runtime

• The code targets Java 8 and uses legacy APIs, including internal sun.misc Base64 classes and SecurityManager.
• The bundled Mosquitto 1.5.5 and OpenSSL 1.1.1a files are historical project artifacts; OpenSSL 1.1.1 reached public end of life in 2023.
• Log4j 1.2.17 is end-of-life. Dependencies are documented rather than automatically migrated so the capstone remains recognizable.
• The repository has no automated tests, reproducible build definition, CI workflow, or project-level license.

Production boundary

• RMI and MQTT connections are unencrypted. Mosquitto is launched without broker authentication or topic access controls, and the Java clients do not configure TLS or MQTT credentials.
• Login is an application workflow, not a complete authorization boundary. Remote methods are not tied to an authenticated server-side session, roles are largely represented in client state, and topic subscriptions are not protected by ACLs.
• The Java security policy grants AllPermission; enabling SecurityManager therefore does not sandbox the processes.
• Passwords are salted and hashed in a Git-ignored runtime file, but the PBKDF2 iteration count is low by modern standards and diagnostic logging includes hash/salt material.
• There is no durable board event log, offline synchronization, or conflict-resolution model. New visitors receive a PNG snapshot, while later updates are transient MQTT messages.
• Drawing payloads use ad hoc comma-delimited strings inside JSON envelopes; large Base64 snapshots and arbitrary text are not designed for scale or hostile input.
• The save/open workflow is local and image-based rather than an editable whiteboard document format.
• Server shutdown uses a Windows image-name taskkill for mosquitto.exe, which can affect another broker process on the same machine.

These constraints are normal context for an older academic prototype. The repository remains suitable for source review and a controlled local demonstration, but the bundled runtime should not be treated as a current production deployment.