JSON-RPC enhancement - getClientCount (only)

[ginjo]

I run a service that manages the full lifecycle of Jamulus Server instances for clients. The JSON-RPC interface is a great help in keeping track of our client's server state(s). Unfortunately, there doesn't appear to be a way to query the server connected-client-count without also getting the full list of clients. This means remotely querying for client count could be a potentially expensive operation, just to get a single integer, especially if running with any short term frequency on servers with high client counts.

So in addition to jamulusserver/getClients, I'd love to see a jamulusserver/getClientCount that simply returns result.connections <integer>. This would help us reduce demand on the Jamulus Servers, the network, and our own server infrastructure. Another option could be a filter expression passed to the server with the RPC request, limiting the objects/fields of the response data. Either would be fine.

[rdica]

Hi @ginjo

I'm just curious but are you querying RPC from a remote host or on the localhost (default behaviour)?
I query from localhost and filter with jq.
I ask because I don't understand how you're defining potentially expensive operation, unless its a remote query.

In any case I forked the main repo and created https://github.com/rdica/jamulus/tree/rpc-getclientcount which adds the RPC method jamulusserver/getClientCount.
I tested building against 3.11.0 and 3.12.0beta1 source.

NCPORT=55924;cat << MYN | $NC -w 1 localhost ${NCPORT}                                            
{"id":"apiAuth","method":"jamulus/apiAuth","params":{"secret":"${RFILE}"}}
{"id":"get_client_count","method":"jamulusserver/getClientCount","params":{}}
MYN
{"id":"apiAuth","jsonrpc":"2.0","result":"ok"}
{"id":"get_client_count","jsonrpc":"2.0","result":{"connections":2}}

Also attaching patch file for same. rpc-getclientcount-20260615.patch.gz

@ann0see I don't expect my code to be a submission for inclusion as it duplicates jamulusserver/getClients to some extent, but if for some reason it's desired, any thoughts/ideas regarding my code would surely be welcome.

[ginjo]

@rdica , thanks! Yes, my service queries the Jamulus servers remotely. It's all within a private cloud network, but the connections/queries can be across the globe.

While reducing unnecessary network traffic is part of this issue, my main concern is minimizing demand on the Jamulus Server's resources. That said, I have no idea how Jamulus Server's performance is affected by queries for client lists. I haven't had the opportunity to set up a benchmarking test for this scenario, so it's possible this could be a non issue 😊

I'll give your fork/patch a spin, thanks for taking the time to work that up!

[rdica]

Before I attempted this I did some testing to see what the size of jamulusserver/getClients results would be because I suspected you were doing remote calls.

With a 10 client load all connected via IPv6 that RPC method could return a JSON blob of ~3-4KB if usernames and cities fields were maxed at 16 and 20 respectively.

Given that IPv4 address space is 32bits and you're not likely using IPv6, that'd significantly drop the size of the output, ~1.5-2.5KB in my tests. Depending on the frequency of the queries and the number of servers being queried I could see a desire to want to reduce network traffic, especially if you have inter-regional cloud traffic.

While anecdotal at best, I haven't seen any performance hits executing RPC queries against active servers, but I am performing my queries on localhost.

Good luck!

[anprdev]

Maybe just a idea
Build a Server who is listen on your control computer.
Send the command getClients and then send back the count and the servername.

[ginjo]

@anprdev I had thought of something similar, if I'm understanding you correctly. I could build a tiny API on the customers' Jamulus server(s) that would receive a request getClientCount from the system application, then query Jamulus Server locally, then return the data to the system application. It would definitely save network traffic, but I doubt it would reduce the toll on Jamulus Server or its processor.

Then again, I'm assuming the toll on Jamulus Server is potentially significant with lots of connected clients, and I could be totally wrong about that. I'll have a setup running here soon that I can test it out on. Thanks for the tip!

[anprdev]

I don't know about the Client Count and what server(PC) you are using. But I think that this still can be fast.
Do you use more than 1 Jamulus Server with many Clients?
If not I have maybe even a better idea for you without using the server to get the client count.

[anprdev]

Maybe checkout my Server Blues/Rock in Any Genre1.
I get the Client count if I like and I don't touch the Server to send me the Clients.
No need to pool this because if the count change you get a new list of clients on the Server.
So if there is a Server Listener on your Control Server. If there is a Server listener the count can be send automatically.
No Pooling needed what most of the time go with a Timer.
Jamulus can handle this if there is the right code to manage this all.
If needed I can help you with this. Love this challenge. lol
Will not be in C++