Page 1 of 1
Much needed implementations(2)
Posted: Wed Aug 05, 2015 12:11 am
by lowpar
1. A "Check for files" option when starting a new torrent. (For removed partial downloads re-added, and for continuing from another torrent client).
I don't like having to start the torrent, then quickly right clicking and checking files before any transfers begin. Lost data from this situation in another client.
2. I have two Ethernet ports, I want to connect both to the internet, and use them both to hopefully manage additional connections for large transfers with many connections. Windows allows network transfers in this way. I want to have both connections used by the client at the same time for individual transfers, or to use both on a single transfer.
Re: Much needed implementations(2)
Posted: Wed Aug 05, 2015 6:01 pm
by ciaobaby
1. A "Check for files" option when starting a new torrent. (For removed partial downloads re-added, and for continuing from another torrent client).
Put the payload in the "Completed" location and it will run a recheck, provided the file and folder names have NOT been changed in the "other client" and there are no 'additional' extensions on the files.
. I want to have both connections used by the client at the same time for individual transfers, or to use both on a single transfer.
You can't, you can only use ONE card because libtorrent has only a single thread for networking IO. If you can 'pair' the cards in the OS, you can use them as a single interface card and the networking layers will handle the packet routing, however this feature is usually only possible in a Server OS and when using two IDENTICAL network cards.
Re: Much needed implementations(2)
Posted: Wed Aug 05, 2015 9:55 pm
by lowpar
Don't they have developers, couldn't you fork the libtorrent and build an alternative?
I have two Ethernet ports, one motherboard. one router/modem hybrid, one internet connection.
I want to use both ports, to remove one bottleneck. I'm thinking that the Ethernet or OS "per Ethernet" can only handle so many peers regardless on how much bandwidth it can handle. So many small connections at once, somehoew preventing additional peers from connecting. I can rarely pass 50 connections...which many time fail to exceed by bandwidth limitations.
By linking the two slots, perhaps I can double the limit.
Re: Much needed implementations(2)
Posted: Wed Aug 05, 2015 10:52 pm
by sledgehammer_999
About your second issue:
https://github.com/qbittorrent/qBittorrent/issues/639
About your first if it is happening then it is a bug of libtorrent. It should start rechecking the files after you add them and point them to the same folder (with the same names).
Re: Much needed implementations(2)
Posted: Thu Aug 06, 2015 11:37 pm
by ciaobaby
couldn't you fork the libtorrent and build an alternative?
Are you volunteering??
By linking the two slots, perhaps I can double the limit.
No.
Re: Much needed implementations(2)
Posted: Sat Aug 08, 2015 8:01 pm
by lowpar
ciaobaby wrote:
couldn't you fork the libtorrent and build an alternative?
Are you volunteering??
By linking the two slots, perhaps I can double the limit.
No.
Informing the developers of a situation is not an acceptable circumstance for your inappropriate sarcasm.
Computers have thresholds and bottlenecks at all points. Using two ports will indeed increase something, end of discussion.
The debate would be if the increase is a waste of time.
Re: Much needed implementations(2)
Posted: Sat Aug 08, 2015 10:38 pm
by Switeck
Best bet is to run 2 separate BitTorrent clients -- 1 bound to each Ethernet interface.
They won't reliably see each other as local peers/seeds though. So unless seeding, it's generally a bad idea for both BT clients to run the same torrents because they're overwhelmingly likely to download the same parts from other peers/seeds.
There can still be a big speed boost by doing this, but it won't be 2x...maybe 1.8x at best with only 1.2-1.5x being far more likely, assuming you have enough busy torrents to keep them occupied.
The programming needed for a single BT client to handle multiple internet connections through different interfaces is non-trivial, since there has to be download/upload, connections, half-open attempts limits for each interface. This can be made even more complicated if some of these interfaces cannot handle encrypted connections, IPv6, uTP, regular TCP peer/seeds, DHT, LPD/LSD, etc!
Re: Much needed implementations(2)
Posted: Sun Aug 09, 2015 5:34 pm
by ciaobaby
Informing the developers of a situation is not an acceptable circumstance for your inappropriate sarcasm.
Where's the sarcasm?
It's a simple question, all the current developers are volunteers with other jobs, so if you want something that adds a lot of extra work to the project, you had better be prepared to get your hands dirty, metaphorically speaking.
Computers have thresholds and bottlenecks at all points. Using two ports will indeed increase something,
Not by enough to make it worthwhile, especially if you only have one router which is the real bottleneck.
Now, if you were running the machine as a bridge across two vLans each with a separate Internet connection, and you were "load shedding/balancing" across the vLans there could be a significant improvement. Though the potential loss of "permanence" with peer connections would of coursel negate that gain somewhat.