partsharing dosn´t work with bloom.dll

[wasti]

Hello,

PArtsharing on an ADCS Hubs dosn´t work wirh Bloom Plugin.

[Toast (swetoast-deactivatedaccount)]

be a bit more specific if you can how does it fail etc can you run the hub in debug and provide a log etc

[wasti (wasti2k)]

when bloom plugin is activated i can´t download from an user how only has parts from the file. the user would not be found.
I tryed it with apex dc and strong dc.
when i don´t use bloom.dll in the hub, partsharing works.

[eMTee (realprogger)]

If the hub supports bloom filters its the client which should include all information about shared files to the filter sent to the hub. Partial file sharing is a feature unique to StrongDC++ and derivants and most probably they don't add the name of partially shared files to the share list what the bloom filter made from or they don't update the filter towards the hub when a file became shared partially only.
So its a client side problem, a hub has nothing to do with it... moving this one to StrongDC++ with a hope that you get some comment from Big Muscle.

[Big Muscle (bigmuscle)]

Is there some description of what bloom filter in ADC does? ADC specs says only how they transferred, but I'm curious in this exact case. Does it work in following way?

- client searches for TTH
- hubs has this TTH in blooms, so it doesn't have to redirect search request to users
- hubs sends response to the client

If it works in this way then partial sharing would require hub support, but it uses special RES format.
If it doesn't work in this way then I don't understand it at all. Also wikipedia says "False positives are possible, but false negatives are not.", so bloom filters can't return that file is not shared although it is.

[Pirre (pierreparys)]

The bloom provided by the client (on demand of the hub) is only updated when there is a change in your shares , and the "partitial" sharing does not seem to send that info to the hub so the hub does not request a new bloom and this way that "part" will not be found ... :)

[Pirre (pierreparys)]

ps: i think the same is happening when you use the "add finished files to share ..." , don't think that updates the info to the hub neither

[eMTee (realprogger)]

No it works the way :
- client searches for TTH
- hub finds in blooms that this TTH has shared in n clients with high probablility
- hub passes the search request to those n clients only

http://dcpp.wordpress.com/2008/01/07/bloom-filters

I think you should check ShareManager::getBloom and make sure you add the TTHs of the partially shared files, too.

[eMTee (realprogger)]

"add finished files instantly" adds the tth to the hashindex right away, but its the hub which gets the filter from the client, when it is INFormed about the share change. Question is that is it worth to make the hub get the filter after each and every share change because of the functions above. I think it isn't, because in some cases it may generate more traffic between the hub and client than without bloom filters at all.
I think the cleanest solution would be to check if any share change happened because of these two functions within a certain timeframe and if so then send the share changed INF to the hub (and clean the marker when any manual share change happens)