Feature #3412
open
SegmentFetcher: onError signal should report more specific failure information
0%
Description
Currently, SegmentFetcher::onError signal reports general failure information such as "Segment validation fail" or "Nack Error". Only reporting general information on the failure can makes it difficult for the user of the SegmentFetcher to decide if they should re-express an Interest.
For example in NLSR, if the SegmentFetcher fails due to a validation error, NLSR may wish to reattempt if the validation error was due to inability to fetch a certificate, but may not want to reattempt if the signature is invalid.
It would be useful for users of the SegmentFetcher if validation error codes and Nack types were returned in addition.
Updated by Vince Lehman almost 10 years ago
- Blocked by Feature #1872: Validator: error code added
Updated by Vince Lehman almost 10 years ago
- Related to Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes added
Updated by Peter Gusev over 9 years ago
I would like to add, that it would be useful if non-verified data packet was returned to users of the SegmentFetcher. In some scenarios (video streaming), users may opt to proceed to fetch non-verified data.
Updated by Alex Afanasyev over 9 years ago
This is not really the callback issue. How to verify data and what to do if data cannot be verified should be part of what Validator is doing. If you don't want to validate (or have special logic for verification), then we can have special Validator that is supplied to SegmentFetcher.
Updated by Peter Gusev over 9 years ago
Alex Afanasyev wrote:
This is not really the callback issue. How to verify data and what to do if data cannot be verified should be part of what Validator is doing. If you don't want to validate (or have special logic for verification), then we can have special Validator that is supplied to SegmentFetcher.
I'm having troubles picturing such a Validator. Will there be any callbacks in it and who's going to receive them - SegmentFetcher or the user who supplied this Validator to SegmentFetcher?
Updated by Alex Afanasyev over 9 years ago
When you create SegmentFetcher, you supply an instance of the Validator. Inside the validator, there are set of callbacks to "verify" or "reject" data packet. There are many ways you can implement such a validator.
Updated by Peter Gusev over 9 years ago
In my case, the user of Validator is the application (ndncon), while SegmentFetcher user is the library (ndn-rtc) this application was built with. Thus, receiving callback from Validator in the application for the data that was fetched within the library won't make sense. Or I'm missing something here...
Updated by Alex Afanasyev over 9 years ago
It doesn't really matter what is implemented where. What is going to happen:
- ndncon-specific Validator instance
m_validator - instance of library's SegmentFetcher
m_fetcherthat getsm_validatoras a constructor parameter
m_fetcher calls whatever it needs to retrieve data. After retrieval, it calls m_validator interface to verify data. m_validator either OK's or Fail's the data. If it fails, m_fetcher calls ErrorCallback from this issue. If it wants to allow "proceed", it will simply not call the ErrorCallback.
Updated by Peter Gusev over 9 years ago
Then why special validator is needed here?
When m_fetcher proceeds upon validation error, it needs to supply fetched data to the library and somehow tell that the data is not verified. This information will be propagated to the application, but the data will be used by the library if it was configured to use non-verified data.
Updated by Ashlesh Gawande over 9 years ago
- Related to Task #2965: LSAs should be segmented before they are published added
Updated by Nicholas Gordon over 8 years ago
- Related to deleted (Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes)
Updated by Nicholas Gordon over 8 years ago
- Blocks Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes added
Updated by Davide Pesavento over 7 years ago
- Tracker changed from Task to Feature
- Subject changed from SegmentFetcher ErrorCallback should report more specific failure information to SegmentFetcher: ErrorCallback should report more specific failure information
- Start date deleted (
01/14/2016)
Updated by Junxiao Shi over 7 years ago
- Subject changed from SegmentFetcher: ErrorCallback should report more specific failure information to SegmentFetcher: onError signal should report more specific failure information
- Description updated (diff)
For example in NLSR, if the SegmentFetcher fails due to a validation error, NLSR may wish to reattempt if the validation error was due to inability to fetch a certificate
How about adding an option to CertificateFetcherFromNetwork and retry within there?
This avoids refetching the whole multi-segment object.