Author Topic: thread shouldn't disconnect from primary to download from backup  (Read 2469 times)

Offline MrbLOB9000

  • Contributor
  • ***
  • Posts: 43
I've been downloading some things that are apparently slightly too old for my main server but my backup server is kinda janky so I don't want to just download it all from there because it's more prone to connection errors.  Anyway, after a while I get errors saying I've reached the max number of connections and have to disconnect and waith a little while before reconnecting and then it works fine, so I guess it's not correctly closing the connection (or my host isn't detecting that it is).

Anyway, why is it even disconnecting to begin with?  Why doesn't it spawn a new connection for the backup server and keep the primary server connected?  doing it that way would be much preferred.

Offline taemun

  • Contributor
  • ***
  • Posts: 16
Re: thread shouldn't disconnect from primary to download from backup
« Reply #1 on: January 12, 2010, 02:32:43 pm »
(the forum is telling me I'm thread digging because this hasn't been touched in four months, but if I made a new thread I think it would get locked and pointed at this one so.....)

I'd like to second this. Unsure why no one else thinks this is useful.

I get around 6MB/s over 10 connections from primary. And 3MB/s over 10 connections from backup.

When a part is missing on the primary, Alt.Binz disconnects the flow to the primary, and connects to the backup. Once that single part is finished, it kills off the backup connection, and initiates a new connection with the primary.

As login times are not trivial, I often see the overall speeds dropping to a couple hundred KB/s when this is happening.

It would be preferable if Alt.Binz either:
>> Kept the primary connection "warm", and just idling for the two seconds it takes to create the backup connection, and get the missing part. And also keep the backup warm (until some defined timeout / server kills connection).
>> Keeps trying to download additional parts on the primary whilst the backup thread is spawned and does its thing. This way you could have a list of parts that aren't available on the primary being made in the background, and have a separate pool of backup threads which download from the list.

The second option is the best from a speed perspective, but is probably a little more complex to implement.

Offline Hecks

  • Contributor
  • ***
  • Posts: 2011
  • naughty cop
Re: thread shouldn't disconnect from primary to download from backup
« Reply #2 on: January 12, 2010, 08:42:32 pm »
There has been more discussion of this in other threads, but I'm too lazy to find em. :P

To answer your first question, I'd say that there's generally less interest in backup server features these days because, for most people, no combination of primary and backup is likely to beat on cost and features Astraweb at $11 for 500+ days retention, 20 connections, unlimited dl, SSL and few problems of completion that can't be repaired.  So the solution to this kind of problem increasingly is: get a better provider and forget about fiddling with backup servers.

Offline taemun

  • Contributor
  • ***
  • Posts: 16
Re: thread shouldn't disconnect from primary to download from backup
« Reply #3 on: January 13, 2010, 03:08:55 am »
The primary was Astra and the backup was Giganews.

Yes, Astra has missing parts. Lots of them. As does Giganews.

I only use 10 connections with Astra because that's all I need to max out the line :P

Offline Hecks

  • Contributor
  • ***
  • Posts: 2011
  • naughty cop
Re: thread shouldn't disconnect from primary to download from backup
« Reply #4 on: January 13, 2010, 09:22:30 am »
LOL :D

Well, all I can say is that, after a year of using Astra exclusivey, I've not once needed a backup server.  Every (minor) problem with missing parts has been solved by PAR2 repair.  I can't speak for others, though, obviously.