Again this would use one (or more) of the following methods:
* domain suffix of the computer
* domain suffix of a domain-connected client
* connection-specific DNS domain
Note: I would still advocate the potential for administrative override or disabling of one or more discovery features akin to those listed [topic=12978]here[/topic] ([topic=12978]Autodiscover UltraVNC repeater using DNS[/topic])
For example:
If a user wants to connect to computer1.domain.suffix then UltraVNC would do a DNS lookup for one or more of the following:
* ultravncrepeater.domain.suffix/ultravnc/repeater.xml
* domain.suffix/ultravnc/repeater.xml
Note: I think that it would be important to allow the optional use of a subdomain (but only because I have a domain that I cannot add a subdomain to (overly political issue!))
The file/service would then return the IP of the proxy and the port it is listening on (and possibly config settings but that's another request...
)The actual name URL can be anything but it would be useful if it was unique to the UltraVNC repeater.
One of the benefits of using a web service is that the client can ensure the identity of the server with the repeater IP using just a standard SSL certificate (anything to save me money!).
It would also be nice (although I might not use it myself) to support the use of authentication to retrieve the repeater IP/settings - that way only authorised users can detect the proxy IP/port.
To my mind this is a fair bit of work even if it doesn't involve modifying the server or repeater settings directly! Thanks again to the hard-working dev's! (and the forum admins/moderators too of course...
)