[ADC-Ext 1.0.6] Backup Hub Addresses

[darkKlor]

This was discussed on DCDev in late-July and early-August (by myself, FlipFlop, Thor, and Pretorian), but never added to ADCPortal, and I'm typing it up now because I faced a perfect use-case this past weekend.

The situation was that I was staying at my girlfriend's for the weekend, but had remote desktop access to the LAN at my residence to manage our local hub. Unfortunately, for some reason my router dropped it's connection to the LAN, and didn't recover it, so the folks on the LAN were left hub-less for a couple days.

The proposal is to add a parameter to the hub's INF message which gives a list of failover hub addresses to try connecting to when reconnecting to the hub fails for a period of time or on a number of reconnect attempts. When disconnected from a failover hub address, the client would attempt to reconnect to the primary address (one attempt per failover, I suggest) prior to attempting to connect to the next failover address.

I (well FlipFlop, really) propose the parameter to be named FO (failover), and value to be a comma-seperated list of well-formed ADC/ADCS addresses.

This feature would be implemented, at a minimum, for favourite hubs. If clients have any concerns about where a hub may redirect users to, or about storing the extra state information, then it may avoid implementing this for non-favourite hubs.

A client must prominently state to the user when it is redirecting to a failover hub, and provide a message explaining what has occured e.g. "The hub <Favourite Hub Name> (<Favourite Hub Address>) has failed X reconnect attempts. DC++ is automatically redirecting you to the backup hub address <Failover Hub Address>".

The time or number of reconnect attempts to wait before the failover is up to the client, and preferably should be configurable by the user.

[Pretorian]

Somewhat more succinct, I think;

=== FO - Failover hub addresses
If a hub goes down, the client's only option is to keep re-trying the last known hub address. This extension will add a list of failover hub addresses, that the client can try to connect to, if the main hub address fail.

Clients should decide the frequency of connection attempts (for the main hub as well as the failover addresses). The client must try connecting in the specified order.

The client should display an appropriate message to the user that it has connected to a failover address.

This extension should be implemented, at a minimum, for favourite hubs. If clients have any concerns about where a hub may redirect users to, or about storing the extra state information, then it may avoid implementing this for non-favourite hubs.

Field FO in the hub's INF:
[options="autowidth"]
|=====
|FO |Failover hub addresses. Specify well formed ADC or ADCS URI addresses, with multiple addresses separated with a comma. Example; FOadc://example.com:1234,adc://example.net:1234
|=====

[darkKlor]

Looks good.

[Quicksilver]

yes looks nice ...

Though it feels like:

The client "must" try connecting in the specified order. -> The client "should" try connecting in the specified order.

would be more appropriate. This should make it clear that a client doesn't have to connect to backup hubs but could also wait for the original hub to pop up again. Though I assume this must is all about the order and not a foce move the client may not veto.

[darkKlor]

@Quicksilver: The intention was that all the users from the offline hub are kept in the same hub, rather than becoming fragmented over many hubs.

Random reconnect times from clients would spread the mass-join load on the backup up, but I don't think you should mandate that.

If a client just waits for the original hub to return then you can look at it as:
a) The client technically complies with FO, but an infinite number of primary hub reconnect attempts are made before attempting to connect to the first backup.
b) FO is disabled and the FO list is never even read by the client upon a hub failure.
c) FO is not implemented.

I think the number and frequency of reconnect attempts to the primary hub, before trying the backup, should be configurable by the user, but that isn't essential.

@cologic: I'd just cycle back to the start of the list myself. I had said in my original post, though it seems to have been lost in Pret's rewrite, that I thought the client should try to reconnect to the primary between each attempt to connect to the failovers - I guess that is an implementation detail though. I don't know if the client should try multiple times for each backup... if the backup hub is facing a mass influx then perhaps sometimes the connection timeout will be reached and that user will end up feeling lonely in the next failover address. I don't think how the client handles that needs to be specified, but some kind of recommendation in the non-existant supporting documentation wouldn't hurt

[mappy]

We've been thinking about this a lot in our situation for campus hubs. How about, instead, support linking hubs together? Like IRC or OpenNAP networks. Then you get the advantage of multiple hub servers in case one goes down, without the disadvantages of wildly variable load and confusion over addresses.

[darkKlor]

We've been thinking about this a lot in our situation for campus hubs. How about, instead, support linking hubs together? Like IRC or OpenNAP networks. Then you get the advantage of multiple hub servers in case one goes down, without the disadvantages of wildly variable load and confusion over addresses.

Have you tried http://dc-hublink.sourceforge.net/ ? I've never used it, but I believe it only allows cross-hub chat, not downloading.

There is a protocol extension proposal for linking hubs: http://www.adcportal.com/wiki/index.php ... sions#LINK
Perhaps you could push for further development of that proposal in a new thread?

[Pretorian]

Pushed in official ADC-Ext 1.0.6.