Directory servers Rock, Jazz and Classical with very long response times....

[dcorson-ticino-com]

Directory servers Rock, Jazz and Classical appear to be down....
But they aren't.
You just need lots of patience, over a minute.
The other Directories are fine.
Any ideas what could be happening there.
This is not the first time I have noticed similar flakiness of these servers.

[gilgongo]

The ones you list are all CNAMEs in the DNS - could that be a factor perhaps? CNAME resolution is slower in theory (but a minute is obviously a bit much...)

anygenre1      IN A      62.113.206.102                ; CENTSERV_ANY_GENRE1 port 22124
anygenre2      IN A      62.113.204.131                ; CENTSERV_ANY_GENRE2 port 22224
anygenre3      IN A      62.113.204.131                ; CENTSERV_ANY_GENRE3 port 22624
rock           IN CNAME  jamuluscentral4.drealm.info.  ; CENTSERV_GENRE_ROCK port 22424
jazz           IN CNAME  jamuluscentral3.drealm.info.  ; CENTSERV_GENRE_JAZZ port 22324
classical      IN CNAME  jamuluscentral5.drealm.info.  ; CENTSERV_GENRE_CLASSICAL_FOLK port 22524
choral         IN CNAME  jamuluscentral7.drealm.info.  ; CENTSERV_GENRE_CHORAL port 22724

~$ host rock.jamulus.io
rock.jamulus.io is an alias for jamuluscentral4.drealm.info.
jamuluscentral4.drealm.info is an alias for peter.drealm.info.
peter.drealm.info has address 81.174.155.168

~$ host anygenre1.jamulus.io
anygenre1.jamulus.io has address 62.113.206.102

[dcorson-ticino-com]

When this happens, it would be useful to know whether Jamulus Explorer can see them.

I don't know if there is a delay, but after 10min before sending the IP to people I did check the explorer and it was working.

[pljones]

The machine hosting these is a general purpose domestic server. Other workloads (including Jamulus development work) may cause the CPU to have heavy load and worsen the response time. Occasionally the domestic DSL connection may get maxed out, too.

Just keep trying.

[pljones]

The solution is hosting the directory servers elsewhere, if someone's willing to do it. We've been considering more global distribution (rather than Frankfurt and West Ealing), too. Perhaps we could look at one per continent for the genre-specific server (excluding Europe).

[ann0see]

It would be great if we didn't have to depend on directory servers at all:

Maybe introduce some kind of decentralised server to server connection could be worked out? You'd be able set any server as "network entry point" which then tells you about other servers in a Jamulus network. It's probably a big protocol change.

[hoffie]

Mesh/P2P network stuff gets complicated quickly, IMO. :)

Making the existing directory servers highly-available would be another option. This would require some way to sync state though. I can think of the following options:

1. Make registering servers send their registration message two multiple endpoints for the same directory server. This risks servers getting out of sync (i.e. registration working on one, but not on the other).
2. Attempt to duplicate incoming registration traffic on the Directory servers via iptables or via a proxy. I fear that this may not work without further effort as this traffic will now look like it was originating from the primary Directory server. This risks servers getting out of sync (i.e. registration working on one, but not on the other).
3. Have a secondary directory server sync lists from a primary server.

• I think this would still need new protocol messages (as the client-targeted messages do not cover all details such as both IP addresses) and new logic in the server.
• Another option would be to do this out-of-band. Make the primary server write out the current list of servers (including all internal fields), make this accessible using a web server, have the secondary server pull that list and update its own state.
• Yet another option would be to make this a seperate component which only performs directory server duties and had such features for syncing.

So, this might imply to accept some complexity, but I'd rather have this complexity next to the directory servers and not in the whole network of Jamulus servers.

[pljones]

There are problems with combining all the server lists -- in addition to the UDP fragmentation issue -- all of which would need protocol changes to address.

[gilgongo]

@pljones

The solution is hosting the directory servers elsewhere, if someone's willing to do it.

We could put them (or some of them?) on the machine that's hosting the jamulus.io domain. That's got a lot of capacity free and will likely remain so for the foreseeable.

[ghost]

What about a local cache? Maybe the last good cache can be used until it is successfully updated. Thereafter, the cache only need be updated on demand (as it currently is), and not more frequently than possibly 2 minutes. This addresses network load, and the temporary lack of a server directory. File locking (or numbered write caches) may be needed for muliple client use.

[dcorson-ticino-com]

I am thinking more along the lines of Favorites so that one can at least access the servers that one uses often can be accessed without going through a directory server.

[gene96817]

A local cache would reduce the traffic demands on the directory. The most important information from the directory is the list of new servers going live. Servers going off-line can also be determined by their non-response to pings. For the most part, we don't need very fast update of servers going on- or off-line.