Link --serverpublicip desc. to docs

[gilgongo]

As per jamulussoftware/jamulus#954 (comment)

[pljones]

This is not a requirement when running a Central Server on a LAN. Rock, Jazz, Classical/Folk, Choir/Barbershop all run on my LAN here (192.168.1.x internal address). Nothing needed other than a public static IP and port forwarding on the router. So I think the new text is somewhat misleading.

[gilgongo]

OK do we mean, "Allows servers to be seen on the Internet when listed by a Central Server behind a NAT firewall"? Or maybe, "Allows servers running on a LAN to be seen on the Internet when listed by a Central Server on their network"?

[pljones]

Ah, sorry, I've just tested the explicit scenario. This is when both servers are inside the LAN, behind the NAT wall.

So I've just started up jamulus.drealm.info:21224, port mapped by the router to internal port 55850. I registered that on jamuluscentral.drealm.info:22824.

This confuses Jamulus Central and completely stops my connecting internally....

I'll try again with the --serverpublicip -- on the registering server.

[gilgongo]

Yes, sorry, this is the whole point of the --serverpublicip option as I understand it. Of course, if you are running the directory on your LAN with servers on that LAN and don't want clients on the WAN in those servers, then it's not needed.

(Note how the use of the word "Directory" nicely disambiguates "Server" in this convo - possibly a bit of an edge case example, but still)

[pljones]

I'm trying to get a server on my LAN registered with a directory on the LAN and exposed to Jamulus Central (which is a Jamulus client outside my LAN for purposes of testing).

[hoffie]

What does this mean? If you mean the code, then you can see the commit in use in the screen shots.

Sorry, missed that. Everything looks good then.

The problem only happens when trying to use port forwarding as well. It's just the --serverpublicip syntax doesn't support supplying a public port as well as a public IP.

Ah, right, you mean forwarding a specific port on your public router/firewall to a different internal port. I talked to @genesisproject2020 about adding support for this scenario as well, but this would require a change in the protocol (PROTMESSID_CLM_REGISTER_SERVER). For now, it wasn't deemed necessary.

So yes, the current code/protocol only supports supplying a different IP address. Both internal and external ports have to match.

[gilgongo]

OK so in terms of my suggested wording for the docs (which in this PR is supposed to be a summary, with the full description here) - does anything need to change?

[pljones]

It needs to say how to use it, not what it does.

[gilgongo]

The pattern we have adopted for other things on this page is to summarise the use here and then link to the corresponding docs. If we try to put all the explanation into the table it'll get very cluttered.

[pljones]

--clientname | Window title and JACK client name

So something like --serverpublicip | Supply the server public IP address

[pljones]

Ignore what I was saying, I was testing wrong...

[ann0see]

Mentioning @hoffie here since he introduced this code and might want to comment. I'll unsubscribe from this issue.

[hoffie]

This is when both servers are inside the LAN, behind the NAT wall

Right

Mentioning @hoffie here since he introduced this code and might want to comment. I'll unsubscribe from this issue.

Happy to help, but I'm a bit confused by the tests.

@pljones:
Do you think that something is broken what has been working before? If so, what exactly?
Do you think that something does not work which you expected to work after the PR?

[pljones]

Do you think that something is broken what has been working before? If so, what exactly?

No, this is new. The breakage that exists existed before as I've shown.

Do you think that something does not work which you expected to work after the PR?

I thought this was going to allow both public IP and port to be supplied (no idea why - I clearly was in too much of a rush when reading the code). It doesn't -- it works the way it's written to work.

What it still doesn't do (even with the logging that's been added) is syntax check the argument and complain if it's invalid. So I can try to supply public IP and port --serverpublicip 81.174.155.168:21124 but this then gets ignored.

So all I'm really saying is "it would be nice if it could handle the port, too" -- either log a complaint that it's not supported or actually, better yet, have the directory server expose the port when a request come in from the outside world.

[pljones]

It's good enough. The fuller docs need to say when it makes a difference. May it could say "see notes for where needed" here, or something - but I'm approving as is.

[hoffie]

What it still doesn't do (even with the logging that's been added) is syntax check the argument and complain if it's invalid. So I can try to supply public IP and port --serverpublicip 81.174.155.168:21124 but this then gets ignored.

So all I'm really saying is "it would be nice if it could handle the port, too" -- either log a complaint that it's not supported or actually, better yet, have the directory server expose the port when a request come in from the outside world.

Good point. I have implemented a quick validation to make it less confusing (jamulussoftware/jamulus#1004). If there's need to support the port as well, I can look into it. As said, it might need a protocol change (or at least a field re-definition). I suggest to do that only as use cases come up in order to keep the codebase as simple as possible.

[pljones]

If there's need to support the port as well, I can look into it. As said, it might need a protocol change (or at least a field re-definition).

Getting port mapping "working" for a registered server (whether the directory server has the same public IP or not) has been on my list of things to look at for a while -- I've had no time available to actually do any work on anything recently, though.