Specify Redirect on Hub Disconnect
Moderator: Moderators
Specify Redirect on Hub Disconnect
It would be helpful if it were possible to enter a back-hub hub in the options for favorite hubs so that, if one were disconnected from a given hub due to a hub reset, they would automatically be redirected to a specific "back-up" hub of their choosing. This could also potentially take some of the load off of OPs trying to maintain the integrity of their hub network during upgrades/unexpected crashes & etc... because they could specify optional hubs to use as back-ups if a given hub goes down and users could then make their own decision for a back-up hub. Overall, it allows for greater automation.
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Hubs could do this well enough their side with some simple network monitoring tools, control of their DNS server, and some shell scripts.
(sorry, workarounds to features are my first thought here)
It might get difficult because some hubs have more than one backup, so some people might want an arbitrarily long list of hubs as backups.
(sorry, complications are my second thought)
Ok.
(sorry, workarounds to features are my first thought here)
It might get difficult because some hubs have more than one backup, so some people might want an arbitrarily long list of hubs as backups.
(sorry, complications are my second thought)
Ok.
It is certainly true that some of these issues can be handled very well with hub-side tools. One of the main advantages I see to a client-side feature allowing input for back-up hub preference, is that an individual user can decide to enter a different hub than where they would normally be transferred to. Also, I find that more often than not OPs simply decide to reset without transferring. This could be because they don't have a very intricate network built-up and thus don't have the capacity to transfer all users from one hub into a different hub. The 'back-up hub preference' feature would not only spread out the user load across many different hubs, but, more importantly, makes it much more certain that all users will remain connected to at least one hub. This then minimizes the discrepency between users whose intention is to be connected to a hub or N number of hubs, and users who are actually connected to N number of hubs.
I think giving users this option also allows for greater share relevancy in those users who tend to share only one type of thing (e.g. anime, music, etc...). Many times an OP in a hub dealing with one specific thing (for example music) will send users to a back-up hub having nothing to do with that thing. In this case it is much better if the user has a music related back-up hub that they specified instead. This then maximizes the relevancy of their share. The opposite also holds true. If a user in a hub dealing with many different file types is redirected to a hub dealing with only one thing, then the relevancy of their share is not maximized. It would be much better for the user to have a generalized hub specified as their back-up hub preference. Anyways, that's one of the main advantages I see to the client-side back-up hub preference idea.
I think giving users this option also allows for greater share relevancy in those users who tend to share only one type of thing (e.g. anime, music, etc...). Many times an OP in a hub dealing with one specific thing (for example music) will send users to a back-up hub having nothing to do with that thing. In this case it is much better if the user has a music related back-up hub that they specified instead. This then maximizes the relevancy of their share. The opposite also holds true. If a user in a hub dealing with many different file types is redirected to a hub dealing with only one thing, then the relevancy of their share is not maximized. It would be much better for the user to have a generalized hub specified as their back-up hub preference. Anyways, that's one of the main advantages I see to the client-side back-up hub preference idea.