Add CLM protocol to get Welcome Message

[softins]

Short description of changes

Adds two CLM protocol messages: one to request the server's Welcome Message, and the other to respond with it.

CHANGELOG: Server: Add protocol for requesting a server's Welcome Message without connecting

Context: Fixes an issue?

Provides a way for a client to fetch the Welcome Message without needing to start an audio connection.
It will be very useful for Jamulus Explorer, and could be used in the future by a Jamulus client.

Does this change need documentation? What needs to be documented and how?

Not at present. It is documented in protocol.cpp. If in the future a Jamulus client uses the feature to fetch a Welcome Message, that usage would need to be documented.

Status of this Pull Request

Ready and tested.

What is missing until this pull request can be merged?

Just review

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[dingodoppelt]

Looks perfectly fine (by the code, that is. haven't tested, yet)
Could it be useful if we somehow logged requests like this one (or server features cl message)?
I just recently noticed some client was connecting to my public server every 30 seconds to do whatever. I only noticed because the connection was logged.

[ann0see]

Meaning we should probably change the client functionality in future to request the server welcome message instead of the server pushing it.

[softins]

Meaning we should probably change the client functionality in future to request the server welcome message instead of the server pushing it.

I don't think there is any point in doing that. The server still needs to be able to push chat messages to the client. The welcome message is just the first chat message to be pushed after connecting. I don't see that as a problem to be solved.

What may possibly be useful would be providing some way within the connect dialog to check the welcome message of a server before deciding whether to connect to it.

[mcfnord]

Showing the welcome message from the connect dialog would be kinda neat.

I've made a welcome message replacement that gives an LLM-derived welcome to joiners. If you made a welcome message visible before joining, I'd make that an LLM-derived general welcome message, too. In the coolest scenario, the welcome message could reveal what the people on the jam are playing now, or whether they're a regular crowd, stuff like that.

@dingodoppelt I think I have a sample cycle on a 29-second cycle, and it's pretty new code, but I think it's connectionless so it wouldn't be a true connection. I think this code is a connection metadata request (names, instruments, countries, jitter). This is helpful to maintain GUI responsiveness. I could probably change the rate to 55-seconds. My systems run on 1-minute chunks so it's useful to have a sample per each minute. Immediately after the metadata request I ask for an audio nibble request for those servers that support this. I have to re-confirm the metadata before gathering the channel nibbles to make sure the channels haven't changed.

I've also re-implemented servers.php to sample metadata more rapidly during prime time and more slowly during slow hours, but I don't think those intervals are ~30s.

[pljones]

Meaning we should probably change the client functionality in future to request the server welcome message instead of the server pushing it.

No - it's the server administrator's decision -- not the client user's. Remember, we still have the client being required to accept the server terms as a server option: the server can refuse the connection at that point. The welcome message forms part of that exchange.

[pljones]

Can I suggest this is loosened a bit.

Currently, the welcome message is sent to the chat window because it looks like a chat message sent from the server to that client.

I'd like the same protocol here with the exception that it's connectionless. The request should come in and, should the server choose to respond (or support the request), the response should go out "looking like a chat message".

I'm hoping that way there can be more reuse of code than the approach here.

(Yes, it still needs two new protocol messages.)

[softins]

Not sure I understand what you're getting at here. The bit FS_HAS_WELCOME_MESSAGE in server features is true if the server operator gave something to -w on invocation, i.e. the welcome message is non-empty. The intention of this message is just to tell the caller what those contents are. I'm not sure what else it could be doing.

And a chat message just looks like | 2 bytes number n | n bytes UTF-8 string |, which is exactly what the contents of this message is too.

[pljones]

I'm not talking about server features.

The server welcome message sent when a client connects to the server is sent as a chat message.

The code to do that exists.

You're writing completely new code to do exactly the same thing here.

Then saying, no, it's not a chat message, it's a welcome message.

That unnecessarily constrains the future use of the protocol message.