Request and receive server features cleanly by cl message rather pretending to connect a client

[dingodoppelt]

What is the current behaviour and why should it be changed?

Currently we can only initiate message exchange with a server by pretending to be a client connecting when we only want to know certain features. There is no mechanism to have the server respond to a request from third-party tools like jamulus-php, jamilizer, jamulusjams, etc.

Describe possible approaches

There should be a connection less protocol message to request and send back server features without initiating a client connection by silent audio packet following immediate disconnection.
As I think that further integration into the client connection process could be tricky (->backwards compatibilty) we should treat this as an API feature for third-party integration first

Has this feature been discussed and generally agreed?

No discussion yet, but some code to be dicussed:
main...dingodoppelt:jamulus:feature-set-cl-message

[softins]

Re compatibility, we shouldn't remove existing mechanisms, but by providing a way of probing for capabilities outside of an audio connection, up-to-date clients would be able to get advance notice of capabilities to enable it to start up a session in the most efficient way.

I would also like the capabilities/features message to include the welcome message. That would enable Jamulus Explorer to display it on request without having to start a short-lived audio connection, and would therefore work even on a server that is full.

[pljones]

I would also like the capabilities/features message to include the welcome message. That would enable Jamulus Explorer to display it on request without having to start a short-lived audio connection, and would therefore work even on a server that is full.

It could do this by triggering the chat message as well as the CLM_RESP_SVR_FEATURES or whatever. Unless chat messages need a connection... Yeah, might not work then.

The problem is the chat messages can be quite big. I'd rather someone sitting on the Connect dialog wasn't probing every server on Any Genre 1 for the Welcome Message constantly.

[softins]

At the moment, the welcome message is only sent in response to the initiation of an audio session. That's why Explorer has to do it that way.

But I can see the value in having a separate CLM message to fetch the welcome message, instead of bundling it with the server features. The connect dialog wouldn't then fetch it (unless we provided a way in the UI to ask for it specifically). But it would be useful for Explorer.

I'll have a go at implementing it that way and raise a PR.

[pljones]

Hi @dingodoppelt,

It looks okay as a start. Not sure bUseMultithreading is ever going to be useful to a client - but may as well include it. You need to include the raw audio one (as "disabled").

The client currently sends CLM_PING "continuously" whilst the connect dialog is open. I think it's also sending the OS and version request continuously. I'd rather not add a third.

Ideally we'd only send the ping continuously and cache the OS, version and capabilities whilst the connect dialog is open (or for a certain extended duration).

(Ah! "CLM_REQ_CAPABILITIES" is probably the better name for the request - and it should support from Client to Server and from Server to Client theoretically).

[softins]

The client currently sends CLM_PING "continuously" whilst the connect dialog is open. I think it's also sending the OS and version request continuously. I'd rather not add a third.

Ideally we'd only send the ping continuously and cache the OS, version and capabilities whilst the connect dialog is open (or for a certain extended duration).

When I implemented the version fetching, I made it only request the version if it didn't know. So it should be only once per server in the list, while the dialog is open on the same directory. We could do the same for capabilities.

(Ah! "CLM_REQ_CAPABILITIES" is probably the better name for the request - and it should support from Client to Server and from Server to Client theoretically).

The naming scheme for protocol ID that Volker used was PROTMESSID_REQ_xxx for the request and PROTMESSID_xxx for the response (or unsolicited message with info).

So in this case, REQ_CAPABILITIES and CAPABILITIES?

Although if you envisage it being used in both directions, we would need a data format that made sense in both directions, or else have different REQ_SERVER_CAPABILITIES, SERVER_CAPABILITIES, REQ_CLIENT_CAPABILITIES, CLIENT_CAPABILITIES. I'm not sure how useful the last two would be?

[pljones]

When I implemented the version fetching, I made it only request the version if it didn't know. So it should be only once per server in the list, while the dialog is open on the same directory. We could do the same for capabilities.

OK, sounds good.

Mmm, OK... KISS says just a pair of message for the server, as that's what we need now. We can add client capabilities later, only if needed.

So in this case, REQ_CAPABILITIES and CAPABILITIES?
REQ_SERVER_CAPABILITIES, SERVER_CAPABILITIES

Yes, REQ_SERVER_CAPABILITIES and SERVER_CAPABILITIES sound good.

[ann0see]

Jamulus 4 should then exclusively rely on capabilities if possible to avoid too many messages being sent back and forth. (My viewpoint)
My standpoint would be to not break compatibility to anything before 4.0 but we can break compatibility with not yet released versions.