search

Figure53 / ActionSync

Code for synchronizing multiple timelines on two or more machines over OSC.
0 stars 0 forks source link

Consider approaches to server redundancy #4

Open siobhandougall opened 6 years ago

siobhandougall commented 6 years ago

As currently envisioned, Action Sync relies on a single server being continuously available. If that server's host should crash or go offline, we don't currently have an explicit solution for how clients should switch to a backup machine's server.

It wouldn't be unreasonable to leave this up to the client's delegate—it can always create two clients, one connected to the main server and one to the backup server. If the main client detects a timeout, the delegate can then switch over immediately to the backup client, send an /actionsync/catchup message, and use that to see if any start or stops were missed in the changeover. However, that requires manual configuration to know which server is main vs backup, and also requires adding a delegate method to handle timeouts (which we need to do in our implementation anyway).

Is there a better approach? We need to let the user manually determine which server is "main", and a fallback order if there are multiple backups, so the sort of automatic election of master that Dante and AVB and such do isn't applicable. But is it worth baking something into the Action Sync protocol, or maybe the discovery portion, that allows a backup server to say "I am backup # 2 for server X"?

samkusnetz commented 6 years ago

i, for one, have no trouble envisioning a manual designation process. currently everyone who uses a redundant qlab setup has to do that anyway, in a sense, so this isn't really adding much mental overhead.