open https://gitlab.synchro.net/main/sbbs/-/work_items/1306

{width=738 height=589}

I noticed my nodered display shows all these connections, however when I investigate there's only me connected via ssh. I checked the logs and I wasn't getting many connections.

Claude investigated a little and its conclusion is that the mqtt receives a connect message as soon as the ip connects to the socket but if Synchronet throttles and kills the connection, a corresponding disconnect isn't send which is causing this backup. Can you please take a look to see if Claude is correct.
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/work_items/1306#note_10752

The terminal server does send a disconnect for throttled and rejected connections. The connections it rejects up front (ip-silent.can, the max-concurrent-connections limit, a temporary login ban, ip.can/host.can) are closed *before* the client is registered, so they never publish a `client/action/connect` at all. The login-attempt throttle runs later, inside the node thread, which always ends in a hangup that publishes the disconnect. A test against Vertrauen confirmed this: two telnet connections (one dropped immediately, one held for a few seconds) each got a connect and a disconnect, and `client/list` returned to its previous contents.

There is a real bug that produces stale entries, though: a client that disconnects while Synchronet's link to the MQTT broker is down is never removed from the server's client list. Its entry then stays in the retained `client/list` (and the `client` "N total" count) indefinitely. This applies to builds that use libmosquitto with an external broker, since mosquitto reconnects automatically after a dropped link. A fix is being prepared that keeps the list current whether or not the broker is connected and republishes the list on reconnect.

To tell whether that's what you're seeing:

1. Does the retained `sbbs/<qwkid>/host/<host>/server/term/client` topic ("N total") also show the inflated count, or the real one?
2. Is your Node-RED display built from the retained `client/list` topic, or from the `client/action/connect` and `client/action/disconnect` events?
3. Internal broker, or an external one (e.g. mosquitto)?

If the display is built from the action events, note that those topics are published *retained* (so each re-subscribe replays the last connect and the last disconnect), and the disconnect payload carries the disconnect time, not the connect time. A flow that matches a disconnect to its connect by the whole line will never find a match. Match on the socket number (last field), or on address + port.

_Authored by Claude (Claude Code), on behalf of @rswindell_
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/work_items/1306#note_10753

1. Left for a few seconds:

```
jsexec mqtt_sub sbbs/EOTLBBS/host/+/server/term/client|grep total
[snip]
7 total 100 max
6 total 100 max
6 total 100 max
6 total 100 max
7 total 100 max
7 total 100 max
7 total 100 max
7 total 100 max
```

It looks like it's displaying the proper totals.

2. node-red is subscribed to sbbs/+/host/+/server/+/client/list for the list of users.

3. I'm still using standalone mosquitto as the broker.
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/work_items/1306#note_10754

Thanks. Since the `client` count is right, Synchronet's client list is right too: the count is the size of the same list that's published as `client/list`.

The display is accumulating entries rather than replacing them. The last field of each line in your screenshot is the socket number, and nearly every entry shows socket 37. Two simultaneous connections can't share a socket, so those rows are connections from different times that each reused fd 37. No single `client/list` message would contain them together.

Each `client/list` message is the complete current list. The flow should replace the displayed list with each message, not append to it. Also, when the last client disconnects, the topic is cleared with an empty (zero-length) retained message. The flow needs to treat that as "no clients" rather than ignore it.

To confirm, compare the raw topic with the display:

`jsexec mqtt_sub sbbs/EOTLBBS/host/+/server/term/client/list`

Separately, the broker-outage bug described above has been fixed in a commit that will reference this issue once it's pushed. That bug only produced stale entries for clients that disconnected while the broker link was down.

_Authored by Claude (Claude Code), on behalf of @rswindell_
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)