linuxdcpp-team team mailing list archive

[eMTee <2009492@xxxxxxxxxxxxxxxxxx>]

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