Author Topic: REAL Multiple serversupport  (Read 14700 times)

bloggs_&_co

  • Guest
REAL Multiple serversupport
« Reply #15 on: March 19, 2007, 10:54:23 am »
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.

Offline meltcity

  • Contributor
  • ***
  • Posts: 22
REAL Multiple serversupport
« Reply #16 on: March 19, 2007, 01:40:11 pm »
Quote from: "Hecks"
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.

bloggs_&_co

  • Guest
REAL Multiple serversupport
« Reply #17 on: March 19, 2007, 03:12:24 pm »
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.