Skip to content

Add CLM protocol to get Welcome Message #3742

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
softins wants to merge 1 commit into
base: main
Choose a base branch
from
+60 −0
Open

Add CLM protocol to get Welcome Message #3742

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions src/protocol.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -472,6 +472,18 @@ CONNECTION LESS MESSAGES

note: does not have any data -> n = 0


- PROTMESSID_CLM_WELCOME_MESSAGE: Server welcome message

@pljones pljones Jun 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 softins Jun 20, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 pljones Jun 20, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@softins softins Jun 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@pljones pljones Jun 22, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's what I'm getting at.

@softins softins Jun 23, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_MESSAGE and CLM_CHAT_TEXT, because they are intended for different purposes:

    • CLM_WELCOME_MESSAGE would be used precisely to respond to CLM_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-mode CHAT_TEXT is. 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_TEXT to respond to a CLM_REQ_WELCOME_MESSAGE is an unnecessary conflation of two concepts, and requires the message receiver potentially to interpret it in context.

  • So I maintain that CLM_WELCOME_MESSAGE as 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.

@ann0see ann0see Jun 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@dingodoppelt dingodoppelt Jun 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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.


+------------------+--------------------------------------+
| 2 bytes number n | n bytes UTF-8 string welcome message |
+------------------+--------------------------------------+


- PROTMESSID_CLM_REQ_WELCOME_MESSAGE: Request server welcome message

note: does not have any data -> n = 0

*/

#include "protocol.h"
Expand Down Expand Up @@ -964,6 +976,10 @@ void CProtocol::ParseConnectionLessMessageBody ( const CVector<uint8_t>& vecbyMe
case PROTMESSID_CLM_REQ_SERVER_FEATURES:
EvaluateCLReqServerFeaturesMes ( InetAddr );
break;

case PROTMESSID_CLM_REQ_WELCOME_MESSAGE:
EvaluateCLReqWelcomeMessageMes ( InetAddr );
break;
}
}

Expand Down Expand Up @@ -2655,6 +2671,35 @@ void CProtocol::CreateCLServerFeaturesMes ( const CHostAddress& InetAddr, const
CreateAndImmSendConLessMessage ( PROTMESSID_CLM_SERVER_FEATURES, vecData, InetAddr );
}

bool CProtocol::EvaluateCLReqWelcomeMessageMes ( const CHostAddress& InetAddr )
{
// invoke message action
emit CLReqWelcomeMessage ( InetAddr );

return false; // no error
}

void CProtocol::CreateCLWelcomeMessageMes ( const CHostAddress& InetAddr, const QString strWelcomeMessage )

@ann0see ann0see Jun 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you could do would be to point to the respective place on the server where the connected welcome message would be sent.

{
int iPos = 0; // init position pointer

// convert chat text string to utf-8
const QByteArray strUTF8WelcomeMessage = strWelcomeMessage.toUtf8();

const int iStrUTF8Len = strUTF8WelcomeMessage.size(); // get utf-8 str. size / string

// size of message body
const int iEntrLen = 2 + iStrUTF8Len; // utf-8 str. size / string

// build data vector
CVector<uint8_t> vecData ( iEntrLen );

// chat text
PutStringUTF8OnStream ( vecData, iPos, strUTF8WelcomeMessage );

CreateAndImmSendConLessMessage ( PROTMESSID_CLM_WELCOME_MESSAGE, vecData, InetAddr );
}

/******************************************************************************\
* Message generation and parsing *
\******************************************************************************/
Expand Down
5 changes: 5 additions & 0 deletions src/protocol.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,8 @@
#define PROTMESSID_CLM_RED_SERVER_LIST 1018 // reduced server list
#define PROTMESSID_CLM_SERVER_FEATURES 1019 // server features message
#define PROTMESSID_CLM_REQ_SERVER_FEATURES 1020 // request server features
#define PROTMESSID_CLM_WELCOME_MESSAGE 1021 // server welcome message
#define PROTMESSID_CLM_REQ_WELCOME_MESSAGE 1022 // request server welcome message

// special IDs
#define PROTMESSID_SPECIAL_SPLIT_MESSAGE 2001 // a container for split messages
Expand Down Expand Up @@ -180,6 +182,7 @@ class CProtocol : public QObject
void CreateCLChannelLevelListMes ( const CHostAddress& InetAddr, const CVector<uint16_t>& vecLevelList, const int iNumClients );
void CreateCLRegisterServerResp ( const CHostAddress& InetAddr, const ESvrRegResult eResult );
void CreateCLServerFeaturesMes ( const CHostAddress& InetAddr, const uint32_t iResult );
void CreateCLWelcomeMessageMes ( const CHostAddress& InetAddr, const QString strWelcomeMessage );

static bool ParseMessageFrame ( const CVector<uint8_t>& vecbyData,
const int iNumBytesIn,
Expand Down Expand Up @@ -308,6 +311,7 @@ class CProtocol : public QObject
bool EvaluateCLChannelLevelListMes ( const CHostAddress& InetAddr, const CVector<uint8_t>& vecData );
bool EvaluateCLRegisterServerResp ( const CHostAddress& InetAddr, const CVector<uint8_t>& vecData );
bool EvaluateCLReqServerFeaturesMes ( const CHostAddress& InetAddr );
bool EvaluateCLReqWelcomeMessageMes ( const CHostAddress& InetAddr );

int iOldRecID;
int iOldRecCnt;
Expand Down Expand Up @@ -376,4 +380,5 @@ public slots:
void CLChannelLevelListReceived ( CHostAddress InetAddr, CVector<uint16_t> vecLevelList );
void CLRegisterServerResp ( CHostAddress InetAddr, ESvrRegResult eStatus );
void CLReqServerFeatures ( CHostAddress InetAddr );
void CLReqWelcomeMessage ( CHostAddress InetAddr );
};
8 changes: 8 additions & 0 deletions src/server.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -294,6 +294,8 @@ CServer::CServer ( const int iNewMaxNumChan,

QObject::connect ( &ConnLessProtocol, &CProtocol::CLReqServerFeatures, this, &CServer::OnCLReqServerFeatures );

QObject::connect ( &ConnLessProtocol, &CProtocol::CLReqWelcomeMessage, this, &CServer::OnCLReqWelcomeMessage );

QObject::connect ( &ServerListManager, &CServerListManager::SvrRegStatusChanged, this, &CServer::SvrRegStatusChanged );

QObject::connect ( &JamController, &recorder::CJamController::RestartRecorder, this, &CServer::RestartRecorder );
Expand Down Expand Up @@ -529,6 +531,12 @@ void CServer::OnCLReqServerFeatures ( CHostAddress RecHostAddr )
ConnLessProtocol.CreateCLServerFeaturesMes ( RecHostAddr, iFeatures );
}

void CServer::OnCLReqWelcomeMessage ( CHostAddress RecHostAddr )
{
// Create and send the message
ConnLessProtocol.CreateCLWelcomeMessageMes ( RecHostAddr, strWelcomeMessage );
}

void CServer::OnServerFull ( CHostAddress RecHostAddr )
{
// note: no mutex required here
Expand Down
2 changes: 2 additions & 0 deletions src/server.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -398,6 +398,8 @@ public slots:

void OnCLReqServerFeatures ( CHostAddress InetAddr );

void OnCLReqWelcomeMessage ( CHostAddress InetAddr );

void OnCLDisconnection ( CHostAddress InetAddr );

void OnAboutToQuit();
Expand Down
Loading