feat: add CLM request for channel level list (message ID 1028)

[mcfnord]

Summary

Adds PROTMESSID_CLM_REQ_CHANNEL_LEVEL_LIST (ID 1028): a new connectionless message that causes a server to immediately reply with the existing PROTMESSID_CLM_CHANNEL_LEVEL_LIST (ID 1015) response.

This follows the established CLM request/response pattern used by:

• CLReqConnClientsList (1014) → CLConnClientsList (1013)
• CLReqVersionAndOS (1012) → CLVersionAndOS (1011)
• CLReqServerList (1007) → CLServerList (1002)

Numbered 1028 because 28 also does this.

Implementation

4 files, 19 lines:

• protocol.h — define ID 1028, declare evaluator, declare signal
• protocol.cpp — add switch case and one-line EvaluateCLReqChannelLevelListMes that emits the signal
• server.h — one-line OnCLReqChannelLevelList slot that calls the existing CreateCLChannelLevelListMes
• server.cpp — connect signal to slot

Zero additional computation. vecChannelLevels is already computed every server tick in OnTimer(). The handler simply forwards that existing data to the requester.

Use case

A monitoring tool can poll the activity level on any Jamulus server by sending a single UDP datagram to the server's game port and reading the nibble-packed level list in the 1015 response. No audio connection, no additional open ports, no configuration required.

The 1015 response already encodes the number of connected clients implicitly (the list length), so the caller can detect idle servers (no clients) versus quiet ones (clients present but all levels ≤ threshold).

Relation to prior PR

This supersedes #3724.

[ann0see]

Way better!

[pljones]

Yes, much better!

[mcfnord]

It says there are branch conflicts that must be resolved, and it says there's a C-like coding style failure.

I can try to fix those if it's inherently a PR you'd merge.

I've found a strong case for the feature, but I plan to try accomplishing similar results on a very lean use of message 28, as recommended here but drawing criticism here.

[ann0see]

If the usecase is beneficial and a simple approach, it would not be rejected by me. However, you want to detect bots/listeners? Then please make clear why you need this. Do we want the client to mark those clients? Does it have any information leakage/privacy concerns?

[mcfnord]

you want to detect bots/listeners? Then please make clear why you need this.

Yes, I want to identify silent connections. Maybe it's a listener, maybe it's a bot that doesn't actually listen, but the thing important to me is: it's not a signal in the sense that we, an audio platform, think about signals.

I use this data in an immediate sense, where it detects someone who maybe has stayed connected while walking away for a while, and also in a long-term sense where I can determine that account xyz is always silent and might not be an active musician (so a perma-listener or a bot).

Do we want the client to mark those clients?

Maybe! https://jamulus.live marks server cards with the "no sound" emoji (🔇) when I determine that every connection on the server is silent. This would be a helpful navigation aide in the Connection dialog. It could be per-connection, although that seems overwhelming. So maybe it just shows that the whole server is silent at the moment.

Notice how people roam around looking for activity... they end up popping in on small groups or singletons to determine if they're active connections. With the "no sound" emoji, I can look at 5 small groups on 5 servers, and see that one is actually making sound. This directs users to the active connection. If the Jamulus client indicated silence this way, it would have the same beneficial effect on navigation.

Does it have any information leakage/privacy concerns?

I can't think of any. It's just a bit, silent or not-silent. Doesn't present an audio sample or additional metadata. It reveals "level of audio" which might have some application somehow, but I can't think of a malicious use for that detail.

I have added this feature to my own server binary and deployed it to about 20 Jamulus servers. I also get the same information through existing connected lounge lobby bots (mostly Thailand). It provides a helpful clue that the server is silent.