Feature set cl message

[pljones]

Short description of changes

Adds two new connection-less protocol messages, one to request and one to return server features.

CHANGELOG: Request and receive server features by connection-less message

Context: Fixes an issue?

Fixes 3710

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

Yes. See below. Will also need updates to Client and Server documentation.

Status of this Pull Request

Proof of concept. Needs:

• Confirmation of solution
• JSONRPC support
• Connect Dialog support

What is missing until this pull request can be merged?

See above.

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

[ann0see]

Could you please also check which protocol messages could be replaced by this?

[ann0see]

Maybe add "has welcome message" also

[pljones]

My view is that it's exposing the operating state of the Server.

If you're running with the UI or using JSONRPC, some state can change (one day, it'll all be controllable, hopefully).

However, it's not for large blocks of data: client list, welcome message, etc.

I see it as providing answers to questions a Client user might have about Server capabilities (I also favour using that term) - so on/off states.

That's why I think it should be stuff that gets shown on the Connect Dialog (although I'm thinking of a "toggle extra connect info" option in Advanced Settings).

[ann0see]

Ok. Can it be used by the client to to enable/disable certain features such as raw audio?
I would say yes.

[softins]

Maybe add "has welcome message" also

Yes, I agree. I plan to add a separate protocol request to fetch the welcome message. Would be useful for Explorer, and we could add a means within the Connect Dialog to right-click on a host and view the welcome message.

[softins]

Ok. Can it be used by the client to to enable/disable certain features such as raw audio? I would say yes.

I'm not sure that's very useful, and may add significant complication for some features, which set up things at initialisation time. I would treat this PR as just a way of exposing information, and any means of control could be investigated and proposed as a subsequent PR.

[dingodoppelt]

--- ./src/server.cpp	(original)
+++ ./src/server.cpp	(reformatted)
@@ -479,15 +479,15 @@
 {
     uint32_t iFeatures = 0;
 
-    iFeatures |= ( !bUseDoubleSystemFrameSize                            << FS_FAST_UPDATE );
-    iFeatures |= ( bUseMultithreading                                    << FS_MULTITHREADING );
-    iFeatures |= ( GetRecorderInitialised() && !GetDisableRecording()    << FS_RECORDER_ENABLED );
-    iFeatures |= ( (JamController.GetRecorderState() == RS_RECORDING)    << FS_IS_RECORDING );
-    iFeatures |= ( bDelayPan                                             << FS_DELAY_PAN );
-    iFeatures |= ( IsIPv6Available()                                     << FS_IPV6_AVAILABLE );
-    iFeatures |= ( bDisableRaw                                           << FS_RAW_AUDIO );
-    iFeatures |= ( bDisconnectAllClientsOnQuit                           << FS_DISCONONQUIT );
-    iFeatures |= ( !strWelcomeMessage.isEmpty()                          << FS_HAS_WELCOME_MESSAGE );
+    iFeatures |= ( !bUseDoubleSystemFrameSize << FS_FAST_UPDATE );
+    iFeatures |= ( bUseMultithreading << FS_MULTITHREADING );
+    iFeatures |= ( GetRecorderInitialised() && !GetDisableRecording() << FS_RECORDER_ENABLED );
+    iFeatures |= ( ( JamController.GetRecorderState() == RS_RECORDING ) << FS_IS_RECORDING );
+    iFeatures |= ( bDelayPan << FS_DELAY_PAN );
+    iFeatures |= ( IsIPv6Available() << FS_IPV6_AVAILABLE );
+    iFeatures |= ( bDisableRaw << FS_RAW_AUDIO );
+    iFeatures |= ( bDisconnectAllClientsOnQuit << FS_DISCONONQUIT );
+    iFeatures |= ( !strWelcomeMessage.isEmpty() << FS_HAS_WELCOME_MESSAGE );
 
     ConnLessProtocol.CreateCLServerInfoMes ( RecHostAddr, iFeatures );
 }

I don't know if the style check is right this time...

[dingodoppelt]

I'd suggest adding two flags to see if the server

1. is using a log file !strLoggingFileName.isEmpty()
2. will show a licence agreement dialog after connection eLicenceType != LT_NO_LICENCE

any objections?

[softins]

I don't know if the style check is right this time...

What OS do you do your dev on? If you have clang-format version 14 installed, you can just do make clang_format before committing and it will format all the style to the same standard as the CI expects.

[dingodoppelt]

I don't know if the style check is right this time...

What OS do you do your dev on? If you have clang-format version 14 installed, you can just do make clang_format before committing and it will format all the style to the same standard as the CI expects.

I use kate on arch. I just used the "format" feature of the built-in LSP-client for the first time 👍

[softins]

Would be good if you can install clang-format. The Jamulus tree has a file with all the correct format rules. Unless that LSP format feature uses the same file of rules?

[dingodoppelt]

Would be good if you can install clang-format. The Jamulus tree has a file with all the correct format rules. Unless that LSP format feature uses the same file of rules?

Yes, that file is used by kate. I just ran clang-format --dry-run --style=file:.clang-format src/* manually for a test and it wants to change lots of comments and some code. Is that expected and why doesn't the auto style check complain?

[softins]

Yes, that file is used by kate. I just ran clang-format --dry-run --style=file:.clang-format src/* manually for a test and it wants to change lots of comments and some code. Is that expected and why doesn't the auto style check complain?

It may depend on which version of clang-format you have. When I had 13, it used to make some unexpected changes. When I moved to 14 it was fine. I don't know about versions newer than that.

[dingodoppelt]

It may depend on which version of clang-format you have. When I had 13, it used to make some unexpected changes. When I moved to 14 it was fine. I don't know about versions newer than that.

Ah, I'm on clang-format version 22.1.6

[dingodoppelt]

The .clang-format file says:

# Style for Clang-Format version 10
# https://releases.llvm.org/10.0.0/tools/clang/docs/ClangFormatStyleOptions.html

Could that become an issue when not updated or is only the comment outdated?

[pljones]

I'd suggest adding two flags to see if the server

1. is using a log file !strLoggingFileName.isEmpty()
2. will show a licence agreement dialog after connection eLicenceType != LT_NO_LICENCE

any objections?

Both make sense to me. I'd actually thought of the licence one myself and forgot to add it!

[dingodoppelt]

How about:

1. Is the server a directory?
2. Is the server registered with a directory?

[pljones]

How about:

1. Is the server a directory?
2. Is the server registered with a directory?

I don't think these are relevant to the use case.

• "Is a Server a Directory?" -- a Client is not affected by this directly. They can go to explorer.jamulus.app and check, if they want to find out. There's no need to add it.
• "Is the server registered with a directory?" -- This doesn't help the Client at all, on its own.

[pljones]

Anyone got anything pending on this?

[ann0see]

Review wise it seems good (we can always add new messages). But we may want to think about where in the client to use this.

[dingodoppelt]

I'd like to leave this in for the moment for documentation purposes. This is supposed to be used for possible future enhancements and I think the comments reflect that well enough.

[ann0see]

Testing with wireshark seems to show that e.g. -L does not get correctly encoded. We might just send one byte over the wire.

[dingodoppelt]

Testing with wireshark seems to show that e.g. -L does not get correctly encoded. We might just send one byte over the wire.

Ouch, I got that terribly wrong. Fixed

[softins]

Testing with wireshark seems to show that e.g. -L does not get correctly encoded. We might just send one byte over the wire.

Ouch, I got that terribly wrong. Fixed

Yes, I found that too, but am still testing. I have a couple of other minor comments. Will post my review soon.

[softins]

A few minor points of style, but other than that, this looks good, and I've tested it.

[dingodoppelt]

A few minor points of style, but other than that, this looks good, and I've tested it.

Thanks for your suggestions! Applied :)

[softins]

Looking good - thank you!

[softins]

... and the comments for the #defines in protocol.h :)

[dingodoppelt]

... and the comments for the #defines in protocol.h :)

Fixed 🤣

[dingodoppelt]

Should I rebase or squash or both?

[softins]

Should I rebase or squash or both?

Probably worth combining the many small commits, so I guess it's a good idea rebasing to current main at the same time.

[pljones]

Merging (I can't approve the PR as I raised it, even though it's @dingodoppelt's code).