do not check all servers always

[segler-alex]

Hi,

i am the author of radio-browser.info in your commit https://github.com/louis77/tuner/commit/7b3b212a360c09eb5b878dba83c2b13744b8c3b8 i saw that you always check every server with /json/stats please do NOT do this. the idea is to randomize the list after generating it and then just use the first one in the list. only if you get a connection issue, continue to the next server in your generated list, and so on... i want to distribute requests to the servers as much as possible, allways checking all servers is not helpfull there and not needed. please reply if you have further questions. greetings and thank you for your cool project!

[segler-alex]

i have to add one or more things:

• only construct the list of servers on program start, and than randomize it and then start by using the first server
• on error, continue by using the second in the already in the first step randomized list.
• please do not call /json/stats at all just for checking if it works. the best way to do it is just using the server. and if it does not work fall back to the next in the list

at the moment traffic is no problem, but i want to optimize this early on, traffic will grow to the servers.

[louis77]

Hi @segler-alex

Thank you very much for creating this issue and keeping an eye on this little project!

You may have seen some code that is commented out. In the commit I do loop over the list of servers and check for a HTTP 200 on /json/stats until the first sucessfull response. So most likely it will always choose the first server, which is a static list of the three currently available servers. I've also reviewed the Grafana traffic stats and noticed that de1 has a lot of traffic compared to nl1 and fr1, so I will randomize the list 👍.

Having said that, I ran into an issue using the proposed strategy as described on https://api.radio-browser.info/. While doing a DNS resolution on all.api.radio-browser.info is fast and straightforward, reverse-resolving the hostnames (3 x IPv4 and 3 x IPv6) takes too much time. I've tried to use the API server with IPs only but then the API didn't respond properly so I assume there is a virtual host config in place.

This is why for now I have hard-coded the list of the three servers just to speed up this process, which is done before the App window appears on the screen.

Maybe you want to implement a strategy using DNS SRV records: https://en.wikipedia.org/wiki/SRV_record or just put CNAME records on the DNS zone so reverse-resolving the IP addresses will not be required any more?

So this is what I'll do for now:

• [x] Step1: Randomize the list of servers on startup
• [ ] Step2: Remove the need to check on /json/stats by implementing a retry strategy based on the randomized list of servers from Step1
• [ ] Step3: Dynamically fetch the list of servers using DNS requests in the background and store that list in the app settings so it will have to be done on every app start

[segler-alex]

hi, thank you for the tip with SRV records, i did now create them. you can check with (on linux shell): $ dig _api._tcp.radio-browser.info SRV or on the web with https://mxtoolbox.com/SuperTool.aspx?action=srv%3a_api._tcp.radio-browser.info&run=toolpage

this is really helpfull because as you said, it does not need a reverse lookup but gives you directly a list of server names. could you try it and use it?

i do not understand what you meant with CNAME. could you explain further what to do there? CNAMEs are just links to other DNS names, but they get translated to IPs and that is not what a client would need. you need the real name because of the SSL certificate. the certificate references the name and is only legal if you use the real name (de1.api.radio-browser.info for example)

[segler-alex]

i added the DNS SRV records as alternative to the documentation at https://api.radio-browser.info/