Alright, so this is all BS, there's nothing wrong with the protocol as
it's now clear that this happens in case of 1-2 updates on small files
only and is caused by a race condition (between the hashing process and
the async calls to the function for compiling and sending the INFs to
the hubs) in the implmentation of DC++.
** Changed in: dcplusplus
Status: Confirmed => Invalid
** Changed in: adchpp
Status: New => Invalid
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2009492
Title:
Certain type of changes in the share do not trigger a Bloom filter
update which makes such changed files temporarily unsearchable by TTH
Status in ADCH++:
Invalid
Status in DC++:
Invalid
Bug description:
Update: rephrase and clarify the initial report.
--------------
There is a problem of not getting a search result for any number of
changed files (same path/different content) in the share after re-
hashing in an ADC client connected to an ADC hub with Bloom filter
support of TTH searches.
The issue is because the hub requesting a new bloom filter only if the number
of shared files are changed in the INF SF coming from the client. In common
examples like when you share an updated binary or change a text file and
reindex this would obviously not happen. For example changing of a fix-sized
metadata e.g. an MP3 IDv1 tag resulting exactly this scenario.
So the filter request is based on an inadequate signal that's not enough for
all common use cases.
A solution would be something that is signalling the share change in
general or also provided the number of re-hashes in the current client
session or maybe the last rehash timestamp. These signals would be
adequate for requesting a new Bloom filter in all cases when files
changed in a client's share.
Of course a BLOM supporting client could force to send an INF SF after
all re-hashes when there is a content change in the share but it is
against the protocol since INFs allowed to send only if any of the
flag values changed and in these special case this would mean sending
multiple INF SF's with the same SF value (see "Each time this is
received, it means that the fields specified have been added or
updated." in https://adc.sourceforge.io/ADC.html#_inf ).
If an extension is allowed to specify new INF fields then a new flag
("SC"?) optionally with parameters containing more data for the hub
about the actual share change, like a last rehash timestamp and number
of changed files. This would probably be the cleanest solution but it
needs a protocol update for the BLOM ADC extension.
Within the currently defined standards another possibility is to do
some client side trickery, an ugly hack to slightly fake SF (eg. by
incrementing it by 1) in each of this special share change casees so
then that'd trigger a BLOM request for an updated filter.
To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/2009492/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~linuxdcpp-team
Post to : linuxdcpp-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~linuxdcpp-team
More help : https://help.launchpad.net/ListHelp
