Alt.Binz forum
New Alt.Binz versions => Requests => Open requests => Topic started by: bugmenot on March 14, 2007, 06:58:20 am
-
I think AltBinz is great, but it would be sooo much better if it has a better support for multiple servers. Currently when a part isn't found on one server, it is kind of "deleted", anyway, these missed parts are not tried again by the other servers available.
This situation undermines the whole idea of having multiple servers, for instance one "main" server which has high speed, short retention and 90% completion and a fill server/thread with lower speed, high retention and/or high completion. Currently these can't complement each other, which would be great if this would be possible in the future.
To see an example of the feature in a program, try PowerFTD or pftd as it is also called.
-
Doesn't this work for you with a primary & backup server configuration, as opposed to only setting up two prrimaries? What you described is exactly how the former is supposed to work.
-Hecks
-
Well, not really, because when I add the extra lowquality servers as a backup to one of the primary's, it isn't used until the highquality primaryservers fail to find a part and the other way around, when I add a highquality primary as a backup to all the lowquality primary's, it doesn't work real good because I can only have 1 thread per highquality backup.
So the whole "primary" and "backup" construction is just too limiting, ideally it should be implemented that when a part isn't found by on of the servers, all the other try it and after that DON'T delete it, but leave it for manual retry. This last thing because sometimes some servers for some reason don't automatically find the part, but do find it when manually retried (maybe because of longer time-out timings).
-
I also agree with bugmenots comments I find the problems caused by having a primary server with backup somewhat restrictive, all servers
need to be able to check for an article before anything is deleted,and yes you can stop parts deleting by adjusting the retry count, but I feel its a bit
like a sledgehammer approach to the problem. I can see why this feature is needed, because there is no manual save on the queued articles, only when the parts have been deleted will the article be saved, that's unless I,vet missed something.
Also it means you have to juggle with servers in order to maximise the download.
Currently due to its better server handling I am using BNR2 to pull articles were I need to maximise my download speed, the program works well in this area, this is on large articles, but using this program for small articles and too get all my NZB`s and editing them as needed to import into the other program. Wish I did not have to!
-
This situation undermines the whole idea of having multiple servers, for instance one "main" server which has high speed, short retention and 90% completion and a fill server/thread with lower speed, high retention and/or high completion. Currently these can't complement each other,
I'm still not sure what you mean. You want to download atrticles from the fast 'main' server first, and if that fails, look for them on the slower 'fill' server. This is how the primary/backup configuration works.
When I add the extra lowquality servers as a backup to one of the primary's, it isn't used until the highquality primaryservers fail to find a part
Isn't that what you meant by the slower one acting as a 'fill' server? Am I missing something obvious?
-Hecks
-
You didn't miss anything obvious I guess, but as explained by bloggs&co, the current solution with primary and backupservers just isn't an ideal solution, in case of optimal downloadspeed, but also in the case of wanting to check the parts manually.
The best way to illustrate I guess is to check the program I mentioned before, PowerFTD, it can be downloaded here: http://www.kapfrank.nl/software/PowerFTD_09c3.zip
-
Not sure I understand you either!
The only ssue I have with the Primary/Backup server configuration is that it isn't possible to set a retention period for the primary server (in my case 3 days for my primary ISP's server), so I get 430 Article Not Found errors for every article on the primary server that is older than 3 days, and the download is slower. If alt.binz knew the retention of the primary server it wouldn't try to download expired articles.
-
I think the point that is being missed is, in an ideal world were you have one server
with high retention and a second server also with good retention and that's all you
wish the program to cater for then it will work fine.
But the other side of the coin is that there could be people who wish to use it on
servers that are not so reliable and you might have say 10 servers and get a bit
from this one a bit from that one etc.
Then as a multi server program its going to fall over a bit. and this is the point
I think that is being made, on good servers it will perform well and not so good
servers it performs somewhat poorer.
-
Still not clear about why - the primary/backup config works just as well in either scenario, IMHO. But I suppose we'll just have to agree to disagree about that one. :)
-Hecks
-
Well that's a bit of a shame, this program was looking to be the bees knees for downloading
binaries, it had just about everything you could ask for but then I found that the server
selection was less then optimum when it came to getting the most out of the servers that
were available at that time,this resulted in endless loops trying the primary server each
time the retry clock got to the end of its countdown then picking up 1 segment from the
backup after first trying the primary (which did not have the article) dropping the backup
trying the primary then backup ad infinitum , still one day you might see the light! hi hi..
Perhaps someone will explain it better. till then as you said we will just have to disagree. Pity about that.
-
I know what you mean bloggs_&_co. I also used powerFTD till now and I like the server setup of that program better. But hey, when we are stuck with this setup. It must be.
For the rest Alt.Binz is a very good program. I am using it all the time.
-
So the problem seems to be that altbinz keeps checking the primary server for file parts, even if the whole archive is missing? Perhaps this logic would work a bit better then:
1. Try to download eveything from the primary server until the end of the queue is reached.
2. If anything downloadable remains in the queue, try to download what's left from the backup server.
3. Repeat 2 for the remaining backup servers until the queue is empty or no more servers remain in the list.
4. If any files are still incomplete, download PAR2 blocks from the last server with a successful download.
5. Repair if needed & unrar.
-Hecks
-
Well yes as I said before you have to juggle with servers, and of course this would not be the
case if each server in your list could independently check for a part before informing the
operator that it does not exist and then allowing the parts downloaded to be saved then checking
to see if enough pars are avialable for repair. the whole object is to get the
computer to do all the donkey work and just enjoy the download that come from it. hi hi
-
No, I meant it would be better if alt.binz followed that logic automatically.
-Hecks
-
Yes, that is how powerFTD works. In setup you mark the servers primary or backup and the outcome is as you discribe. It is than no longer necessary to make backup servers with each primary server.
-
Right Hecks I see what you mean now, yes.. Now I stand to be corrected but think the current setup makes
checking the primary server inevitable if you don`t wish the queue to be deleted, because in order to do
this you have to set the retry count, which makes it go through the same routine again checking each
server for an article which it might not have, at least thats my undestanding.
Now if the retry count is left at zero then you end up with parts missing, depending on how your
servers are set, which I think is one of the hit and miss parts of this configeration.
Your never sure if after the download there are going to be enough pars to correct the problem, when
in fact they might not have been necessary if all other servers had been tested first.
So In my humble opinion I just think something like your suggestion would be the iceing on the cake
if it made better use of whatever servers were available for download.
-
So the problem seems to be that altbinz keeps checking the primary server for file parts, even if the whole archive is missing? Perhaps this logic would work a bit better then:
1. Try to download eveything from the primary server until the end of the queue is reached.
2. If anything downloadable remains in the queue, try to download what's left from the backup server.
3. Repeat 2 for the remaining backup servers until the queue is empty or no more servers remain in the list.
4. If any files are still incomplete, download PAR2 blocks from the last server with a successful download.
5. Repair if needed & unrar.
-Hecks
I don't agree with the above approach.
My backup server is slower than my primary server. Let's say I have 3 connections open. If an article is missing on my primary server alt.binz automatically tries to download it from the backup server.
Although my backup server is slower, the two connections on my primary server will speed up to take advantage of the bandwidth not being used by the backup server. If alt.binz waited until the end of the download to try the backup server the download would take longer because it would be downloading solely from the backup server. I don't think this is the best solution.
In addition, if all the items have expired on the primary server it could take a long time for the download to begin if alt.binz tries to download every article on the primary server before trying the backup! Setting an age for the server would be a better solution to that particular problem.
-
Well the flaw in that argument is if the article does not exist on the primary server it cannot be downloaded from there anyway but the download should continue at whatever speed your primaries can handle until all parts available are downloaded then the backups come into play, the outcome reguarding speed would be the same in my opion. my main point in this discusion is that the current system works but not without juggling with servers I would like to see all servers in the list operate indepently and do not keep checking for articles that do not exist, by whatever method is deemed best by the programer
for what its worth my thoughts on the subject are, servers should be grouped in bands of priority, numbers or titles 1,2,3,4,5 highest,high,mid,low,lowest, the highest group would start downloading, if a valid error code was recieved by servers in the group then the next lower group would start and so on, if you had 7 servers with
30 conections all could be in use at some time, each group would continue to the end of the queue. each server would need to know which articles had been tried
and which had not. so no parts were missed.
Only when all servers had reached the end of the queue whould the retry count come into play, this should default to 1 or 2 and not zero and could still be set by the operator, once the retry count was exceded the articles whould be saved as they are now and attempts to repair them made with the pars. as outlined no servers would be setting waiting for the retry clock to keep pausing servers. And should maximize downloads.