In Selenium Grid, what is the difference between the hub role and the node role?
answer
- One jar, two different roles
- One entry point, many browser machines
- Only one of the two owns browsers
- Client port 4444, node port 5555
- One flag derives the bus addresses
basics
~20 sThe hub is the grid's single entry point: it takes session requests from test clients and hosts the event bus that nodes register on. A node owns a machine's browsers and runs the sessions the hub places on it.
solid answer
~40 sIn Selenium 4 both roles come from the same jar: `java -jar selenium-server.jar hub` and `java -jar selenium-server.jar node`. The hub listens for `RemoteWebDriver` traffic on port `4444` and runs the event bus on `4442` (publish) and `4443` (subscribe); it never launches a browser. A node listens on `5555` by default, detects the drivers available on its own machine, announces itself over the hub's event bus, and then receives session commands from the hub over HTTP. You point a node at a remote hub with `--hub http://hub-host:4444`, which also derives the two event-bus addresses. Traffic is two-way: the node reaches the hub's bus ports to register, and the hub reaches the node's HTTP port to drive sessions, so both directions must be open.
code
bash · 5 lines# machine A: the hub for the tariff-switcher suite
java -jar selenium-server.jar hub
# machine B: a node that joins it
java -jar selenium-server.jar node --hub http://tariff-grid:4444 --port 5555go deeper
Be ready to name both roles, say which one owns the browsers, and give the default ports: 4444 for the hub's clients and 5555 for a node. Knowing that --hub is how a node is pointed at a hub is expected.
Explain that registration flows node-to-hub over the event bus on 4442 and 4443 while session commands flow hub-to-node over HTTP, and describe the three values --hub derives from a single hostname.
An interviewer expects you to reason about both traffic directions when planning firewall rules, and to say precisely what breaks when only the outbound one is open. Be able to justify a hub's sizing against node count.
Own the choice between the hub-and-node shape and a more split deployment, and be explicit about what the hub becomes as node count grows and how you would stage the move without a suite outage.
## One jar, two roles **Selenium 4** ships a single `selenium-server` jar that can take any of several *roles*. Two of them make up the classic Grid: `java -jar selenium-server.jar hub` starts the **hub**, and `java -jar selenium-server.jar node` starts a **node**. The same binary, started with a different subcommand, becomes a different kind of process — there is no separate hub download and no separate node download. The division of labour is strict: - The **hub** is the grid's single front door. It accepts new-session requests from `RemoteWebDriver` clients, holds the picture of which nodes exist and what each can offer, and hosts the **event bus** that nodes announce themselves on. A hub never starts a browser. - A **node** is the machine-level worker. At start-up it inspects the machine it runs on to find the drivers it can use, tells the hub what it can offer, and then serves the sessions the hub places on it. A node is never the address your tests point at. For a suite that regression-tests an **energy-tariff switcher**, that split is what lets one team run the same tariff-comparison and switch-flow tests across a Windows machine with Edge, a Linux machine with Chrome and a macOS machine with Safari, while the tests themselves know exactly one URL. ## The port each role listens on Each role opens its own listeners, and the defaults are worth memorising because a blocked one is the most common first-Grid failure. | Listener | Default port | Opened by | Who connects to it | |---|---|---|---| | HTTP server | `4444` | hub | test clients driving sessions | | Event-bus publish | `4442` | hub | nodes announcing their status | | Event-bus subscribe | `4443` | hub | nodes listening for grid events | | HTTP server | `5555` | node | the hub, calling the node back | `--port` (short form `-p`) overrides the HTTP port of whichever role you started. It deliberately carries no single default of its own, because the flag is shared by every role: the hub falls back to `4444` and a node falls back to `5555`. Two nodes on one machine therefore need distinct ports, or the second one cannot bind: ```bash java -jar selenium-server.jar node --port 5555 java -jar selenium-server.jar node --port 6666 ``` ## Joining a node to a hub with `--hub` A node started with no arguments assumes the hub is on the same machine; its built-in default for the hub address is `http://0.0.0.0:4444`. To join a hub elsewhere you pass `--hub`, and one hostname is enough, because that single value derives three others: 1. the grid URL becomes `http://tariff-grid:4444`, 2. `--publish-events` becomes `tcp://tariff-grid:4442`, 3. `--subscribe-events` becomes `tcp://tariff-grid:4443`. Two details are worth knowing. If the value you pass carries a port — `--hub http://tariff-grid:8888` — only the grid URL uses it, and the event-bus addresses stay on `4442` and `4443`. A scheme in the value is honoured too, so `https://` is respected. Any derived value can be overridden by setting its own flag explicitly, which is exactly what you do when the hub itself was started on non-default bus ports with `--publish-events` and `--subscribe-events`. ## Traffic runs in both directions The most useful thing to hold onto about the split is that it is not one-way: - **Node to hub**, over the event bus: the node publishes its status to register, and then keeps publishing a heartbeat so the hub knows it is still there. - **Hub to node**, over plain HTTP: once the node is registered, the hub health-checks it and forwards every WebDriver command for the sessions it placed there. A firewall that opens only the outbound direction produces the classic symptom of a node that appears in the grid and then goes quiet. Both directions have to be reachable for the pair to work at all. ## What the split does not change - **The contract your tests see is unchanged.** They speak WebDriver over HTTP to one address — the hub's — exactly as they would to a single-machine server. - **Matching stays central.** The hub decides which node a request lands on; a test cannot address a node by name. - **Losing a node is not losing the grid.** Stopping one removes its slots and leaves the hub and every other node serving. - **Adding capacity means starting a process.** A new node joins a running grid by starting and registering; nothing on the hub is restarted or edited.
- Can the hub and a node run on the same machine, and what changes if they do?Yes, and that is the default: a node started with no `--hub` assumes `http://0.0.0.0:4444`, so the pair works out of the box on one host. The only real change is ports. The hub takes `4444`, `4442` and `4443`, the node takes `5555`, and a second node on that host needs its own `--port`. Capacity is still bounded by the one machine.
- Your hub is not on the default ports. What do you pass to the node instead of --hub?`--hub` with a port in it only changes the grid URL; the event-bus addresses stay on `4442` and `4443`. So if the hub was started with `--publish-events tcp://hub-host:8886 --subscribe-events tcp://hub-host:8887 --port 8888`, the node has to repeat those same two `--publish-events` and `--subscribe-events` values rather than rely on `--hub` to work them out.
saying these in an interview costs you the question
- Saying the hub runs the browsers and the node only forwards requests
- Pointing test code at a node's port instead of at the hub
- Assuming a node needs outbound access only, because the hub never calls back
- Thinking hub and node share one port because they share one jar
- Describing Selenium 3 HTTP registration as how a Selenium 4 node joins