Smart "on request" tth

[gnipi 0]

It would be nice to have. Client could publish list of all files, even non-hashed files, and continue hashing in the background, but if some file is requested, background hashing should be stopped and client should immediately start hashing files that are requested for download ... does that make any sense at all ?

[Zlobomir 3]

Yes, it makes sense, but I don't know how useful it will be on practice. Start, stop, hash other files, resume... Isn't it better to wait for the client to finish hashing once?

[gnipi 0]

Yes, it makes sense, but I don't know how useful it will be on practice. Start, stop, hash other files, resume... Isn't it better to wait for the client to finish hashing once?

Actually as I think of it it would take exactly same amount of time in most cases, and 30 seconds more per each interrupted 1 GB file being hashed if we implement hash file abort without proper resume (start from beginning after serving requested) ... there are lot of alternatives here, some of them easy to implement but not too efficient, some completely efficient but harder to implement...

it all depends on you people. it's a feature request ... it can be done. I know how to do it but it would take me at least a month to complete it since I'm much out of C++ last few years, and know almost nothing about win32 gui/ATL stuff.... still it's c++ so it can be done but I suspect it's a 15 minutes work for somebody more PRO ;)

[amp 0]

Great opportunities for those who do not like hashing much.

But how this would work with filelists? When you download list from someone, its already contains info about all hashes.

[gnipi 0]

Great opportunities for those who do not like hashing much.

But how this would work with filelists? When you download list from someone, its already contains info about all hashes.

afaik, when you pick 10000 files to share, more recent builds of SDC++ / Apex / others make filelist without hashes and add hashes as hashing process completes them ... did not look at source code but that's what I see ... all files ... but most of them without tth and size=0 bytes (cause not yet processed) - but they *are* in list so somebody could request to download them anyway ...

Well, here it goes ...

A: Client that shares files (our goal)

B: Any anonymous DC++ compatible client, that requests file form A

order of things:

B requests filelist from A

B downloads filelist from A

B opens filelist and user selects some set of files [C]

B waits for open slot in client A and requests file #1 from list of files

A accepts connection but since file is not hashed, decided:

- for very small files (hmm define "small" ) tth can be calculated on the fly cause it takes only few milliseconds

- for larger files, connection is closed, but file that was "asked for" is removed from queue of "files to hash" and added to head of list (to be hashed next) ... no hashing process is stopped, file will wait till current hash completes.

B Will ask for some other file if slot is still open in client A thus adding that file also to priority hash queue

at some point B might quit but anyway we want all files hashed, so why not make more wanted files hash first ?

this could make hell of a difference at lan party's

(not that I care much I never move my PC out)

if and if only way to request file from client A is to ask for a specific TTH, then this can't possibly work but since I know of some non-tth clients, it must be possible to request filename not tth ...

I hope I'm not too confusing... this should be possible, dunno how complicated it really is till I inspect the code more thoroughly... but I'm more into making my Remote controlled bandwidth management via UDP packets (maybe even based on packet loss) first ...

[datadyne 0]

This would be like the Old DC before there was hasing. The problem is that this would cause a problem for other users and would likely get Apex users banned on the spot. When attempting to access un unhashed file The peer would get a message stating File not available. Most ops will ban you on site for this.

[poy 0]

this idea is surely very good theoritically, but the problem is that some people do searches by TTH (auto-searches, for instance). since ApexDC++ won't be able to answer to some of these TTH searches eventhough you do have the file in your share (but it's not yet hashed), i doubt hub operators would accept this.

[gnipi 0]

Hmm, point is not to enable users to enter hubs with nothing shared.

Imagine 3 terabytes of shared files... takes too long to hash. maybe a day or so. Now, why would anybody want to be absolutely sure about every single file in that share 100% of the time? ok it's great to be sure, but why not share list without hashes, and start hashing in the background (this is already how it's done) ...

and addition will be, that if somebody *wants* to see filelist, he can see it without hashes off course (also already implemented) but if he chooses a file to download, *by*name*, that file should be hashed ahead of it's turn, so upload can start nothing lost here. Just take the file name, and put it to be next to be hashed. Rules about shares on hubs are not our concern at all. It's just more convinient, and could reduce "wait till it's hashed" time to almost 0 seconds... ok if current hashed file is big, like 1 gb, then somewhat longer, but it still could mean a lot if we share hundreds of gigabytes or perhaps terabytes. Am I boring ? :fear:

Exact change needed:

to hashing code: - there is already a compiled list of all files that need to be hashed. Just create one more - separate list of same type and name it priorityList. Hasher will always first take files to hash from priorityList. If priorityList is empty, take from default list.

to code that currently answers sorry - no hash : ... code to insert file requested *by*name* to priorityList.

Nothing more.

Think of it as taking notes on interesting files and hashing them first. Files that nobody asked for will be hashed too, but after files we already have "customers" for.

[poy 0]

this is how some versions of DC++ worked when TTH was first implemented, and it indeed was very cool. however, with the new versions which are very "TTH-focused", i'm not sure this can work, there are TTHs everywhere in every procol command. and with the new ADC protocol, it's even more.

however, if it was still possible do to so, i completely agree with your ideas ;)

[gnipi 0]

this is how some versions of DC++ worked when TTH was first implemented, and it indeed was very cool. however, with the new versions which are very "TTH-focused", i'm not sure this can work, there are TTHs everywhere in every procol command. and with the new ADC protocol, it's even more.

however, if it was still possible do to so, i completely agree with your ideas

I am almost 100% sure it can be done simply enough but I have some things more urgent. I will try to do it when I finish what I already started.