Add CLM protocol to get Welcome Message#3742
Conversation
|
Looks perfectly fine (by the code, that is. haven't tested, yet) |
|
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. |
|
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. |
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. |
| note: does not have any data -> n = 0 | ||
|
|
||
|
|
||
| - PROTMESSID_CLM_WELCOME_MESSAGE: Server welcome message |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The server welcome message sent when a client connects to the server is sent as a chat message.
Yes, because that's how it is displayed to the client user
The code to do that exists.
Yes, in the connected-mode PROTMESSID_CHAT_TEXT
You're writing completely new code to do exactly the same thing here.
That's because connected mode is not appropriate here. There is no existing CLM message that encodes just a variable-length string. And the amount of extra code is trivially small, compared to the size of the code base, so I'm not sure why you think it's a problem.
Then saying, no, it's not a chat message, it's a welcome message.
Well that's true. The request was specifically "send me the contents of your welcome message".
That unnecessarily constrains the future use of the protocol message.
It's not as if protocol messages are in short supply! I do feel it's picking nits for the sake of it, which can be rather exasperating.
But maybe you are just suggesting that we call it CLM_CHAT_TEXT instead of CLM_WELCOME_MESSAGE? I suppose in that case we could use it for sending potentially (but rarely) large welcome message and chat texts over any long-lived TCP connection, in the same way as I propose to use CLM_CONN_CLIENTS_LIST instead of the connected-mode CONN_CLIENTS_LIST. That would address the potential point alluded to in your other comment
There was a problem hiding this comment.
Yes, that's what I'm getting at.
There was a problem hiding this comment.
Yes, that's what I'm getting at.
Well I disagree fundamentally with the objective. And I will explain why. Although it is becoming very tedious always having to explain and defend my position at great length, after putting a lot of thought into my submissions. This PR could have been in 4.0.0beta1 if it weren't for this objection. And it wouldn't be the first PR I have ever closed and abandoned due to unhelpful and intransigent feedback from @pljones. Although in this case, I feel it is too important a feature to abandon.
-
I don't believe there is any problem with having two different protocol messages having a similar or same message format, if they mean different things. In this case there would be no problem in having two messages,
CLM_WELCOME_MESSAGEandCLM_CHAT_TEXT, because they are intended for different purposes:CLM_WELCOME_MESSAGEwould be used precisely to respond toCLM_REQ_WELCOME_MESSAGE, and is unambiguously "this is the welcome message that the server operator has configured". It is intended just to answer that query, and would never contain anything else. It isn't something that needs to be defended against "unnecessary contstraint on future use".CLM_CHAT_TEXT(to be defined in the future, potentially as part of the TCP PR), is more general, meaning "this is to be displayed to the user in their chat dialog", in the same way as connected-modeCHAT_TEXTis. This is a different semantic, and is not negated by the fact that the welcome message happens (by design) to be the first chat text sent by the server to a new client. The difference is context.- Using a
CLM_CHAT_TEXTto respond to aCLM_REQ_WELCOME_MESSAGEis an unnecessary conflation of two concepts, and requires the message receiver potentially to interpret it in context.
-
So I maintain that
CLM_WELCOME_MESSAGEas proposed in this PR is the correct way to do it, and I don't propose to change that.
I would be interested in more constructive feedback and review from @ann0see and @dingodoppelt.
There was a problem hiding this comment.
Please be constructive...
I think it's mainly a style question again?
We need to be clear about why we add all those new messages.
- Until now, protocol messages were almost always for exchanging information between Jamulus Client and Jamulus Server only. This changes with 4.0.0. The PR by @dingodoppelt introducing SERVER_FEATURES might be used by external tools too - better let's say the reason it was implemented was not a client need.
Peter (and me) would probably prefer to use this message in the client some day instead of introducing too many new protocol messages since it feels redundant.
Here, we have a very clear feature specification:
Get the welcome message from a server without connecting. Again from the viewpoint of an external tool (Explorer). For this, it is enough to have a specific response just containing the welcome message.
If we decide that this is just the welcome message, I agree CLM_CHAT_TEXT would be overkill. We don't know yet if there is any feature which will require the server to send a connection-less chat message which for now would make CLM_WELCOME_MESSAGE enough.
Curently, the server has no notion of what a chat message vs a welcome message is (it just does some html based hackery which is unclean engineering).
For now, i would decide that we can go with either definition - however, from a clean semantic meaning, I'd likely go with CLM_WELCOME_MESSAGE and define the scope strictly.
I hope I got this right then and you both can agree?
There was a problem hiding this comment.
+1 for CLM_WELCOME_MESSAGE.
I guess it makes sense to think about turning this new kind of message into something more in line with existing code. We currently only have messages for exchange between a client and a server and from a stylistic point of view I can see why PRs that don't exactly fit that framework are more difficult to review because more consideration goes into every personal review.
I think we might need to acknowledge that the Jamulus explorer has been "exploiting" that design at least partly for years now. Since there is no category for protocol messages that are to be exchanged with anything else than a client we should introduce one with a clear scope: External communication to non-jamulus clilents only. Therefore it'd be possible and probably necessary to add logging to these messages (CLM_SERVER_FEATURES) which would enable admins to use stuff like fail2ban.
| return false; // no error | ||
| } | ||
|
|
||
| void CProtocol::CreateCLWelcomeMessageMes ( const CHostAddress& InetAddr, const QString strWelcomeMessage ) |
There was a problem hiding this comment.
What you could do would be to point to the respective place on the server where the connected welcome message would be sent.
5 participants
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