Run centralserver only

[leoguiders]

Is it possible to run a server instance that itself acts only as a central server, managing a list of servers but is not joinable and itself does not appear in the server list?

I want to have a server with a fixed ip address handling the server list and be able to fire up cloud servers that register to this address without having to mess around with DNS changes. The fixed-IP server is running other services like web and mail server so it is not advisable to use this server for low latency audio processing.

[dcorson-ticino-com]

Yes. please take a look at the server documentation at www.jamulus.io
I am not sure that it doesn't show up in the list, however, but you could set, for example, only 1 user.

[DominikSchaller]

No, sadly it is not possible. It will always appear in the server list. Better set the maxClients number to a value> 1 , otherwise you will end up with clients being stranded in the central server room if they accidentally type it in the Connect input field. And you can't join the server to tell them how to leave it ... So better set it to 2 or 3.

[ghost]

Couldn't the server send a Chat to the client? (How to go away if you are stuck)
Maybe 'Run centralserver only' would be a good feature to have.

[DominikSchaller]

Yes, a welcome message is a good idea.

[leoguiders]

Ok so I will have to implement this feature.

Any opinions on either:

• split the centralserver command-line parameter into two seperate parameters to a) set the address of the remote central server and b) enable/disable local central server function
• use a numchannels parameter of 0 to disable joining the server

I guess the first option would be the cleaner approach. The server would not be listed, still people could join using the hostname or ip address.
The second one would be as "hacky" as the current solution that enables the centralserver and sets the address to localhost at the same time. Maybe I need to implement both.

[hoffie]

Hrm, as far as I understand, what you want to do is already possible by using limiting the numchannels to 0, right? The only downside is that the central server will still list itself, is this correct?

If this is the only problem, then why not special-case numchannels=0 in the central server logic to avoid listing the central server itself?
I haven't checked if there are any obstacles such as "there has to be at least one server listed" though.

split the centralserver command-line parameter into two seperate parameters to a) set the address of the remote central server and b) enable/disable local central server function

I think this would have been the cleaner approach (is always easy to say this in hindsight!), but I don't see a way of implementing this while keeping this backwards-compatible, do you?

[pgScorpio]

Keeping it backwards compatible could be easy.
Just add a (central) server parameter "--hidden"/-H
If this parameter is present the server will not publish itself.
The server would still be accessible by IP though.

[DominikSchaller]

As far as I know you can not set it to 0. Christian Hoffmann ***@***.***> schrieb am Di., 20. Apr. 2021, 23:05:

…

Hrm, as far as I understand, what you want to do is already possible by using limiting the numchannels to 0, right? The only downside is that the central server will still list itself, is this correct? If this is the only problem, then why not special-case numchannels=0 in the central server logic to avoid listing the central server itself? I haven't checked if there are any obstacles such as "there has to be at least one server listed" though. split the centralserver command-line parameter into two seperate parameters to a) set the address of the remote central server and b) enable/disable local central server function I think this would have been the cleaner approach (is always easy to say this in hindsight!), but I don't see a way of implementing this while keeping this backwards-compatible, do you? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1525 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQQ4TYOUPPCOPJWDXVYNJDTJXUCXANCNFSM43A5D64A> .

[hoffie]

Ah, I see, yes. This part should be easy to modify though.

What's not that easy (it seems), is the index 0 special casing in both server list manager and clients. I don't see a way to remove this without changing client logic.

@leoguiders What about giving the central server a clarifying name such as "(Ignore this entry)" or something similar, maybe in addition with a way to set the number of acceptable users to 0?

[leoguiders]

@leoguiders What about giving the central server a clarifying name such as "(Ignore this entry)" or something similar, maybe in addition with a way to set the number of acceptable users to 0?

@hoffie well yes, this is the workaround I am using but that's not clean software-development, is it? ;-)

I don't see a way of implementing this while keeping this backwards-compatible, do you?

Keeping it backwards-compatible would be:

• -e localhost activates the centralserver and registers to itself
• -e hostname/ip registers to a remote central server
• -E (new parameter) activates centralserver without registering to itself, maybe --centralserver without a string parameter could also work
• -u 0 creating a server without any channels, effectively preventing clients joining

This would allow running a local centralserver and registering to a remote centralserver at the same time - I don't see a use case for this but I also don't see why this needs to be prohibited.

There is a third option I am thinking of: building a seperate centralserver executable that does not contain all the audio stuff the centralserver does not need. The disadvantage is that you have to maintain this separate logic apart from the regular client.

[hoffie]

well yes, this is the workaround I am using but that's not clean software-development, is it? ;-)

I agree that it would be a workaround, yes.

What you suggest would enable the server-side part, yes. However, I still think this would need adjustment in the client-side special-casing of index 0. Otherwise, the central server itself would be hidden but the first registered server would not work properly:

jamulus/src/connectdlg.cpp

Line 338 in 6d662e3

CurHostAddress = InetAddr;

And if we had to touch this place as well, I'm wondering whether it's still worth the effort :(

[passing]

A Jamulus Client will always try to connect to the Central Server directly, when you connect to the Server at Index 0.
But you can achieve, that the Jamulus Client hides that entry, by simply not letting your Central Server respond to CLM_PING_MS_WITHNUMCLIENTS messages.

jamulus/src/connectdlg.cpp

Lines 344 to 349 in 6d662e3

	// make the entry invisible (will be set to visible on successful ping
	// result) if the complete list of registered servers shall not be shown
	if ( !bShowCompleteRegList )
	{
	pNewListViewItem->setHidden ( true );
	}

[hoffie]

That sounds like an interesting hack :)