Project

General

Profile

Actions

Feature #3412

open

SegmentFetcher: onError signal should report more specific failure information

Added by Vince Lehman almost 9 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Utils
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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.


Related issues 3 (1 open2 closed)

Related to NLSR - Task #2965: LSAs should be segmented before they are publishedClosedMuktadir Chowdhury06/26/2015

Actions
Blocked by ndn-cxx - Feature #1872: Validator: error codeClosedAlex Afanasyev

Actions
Blocks NLSR - Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codesNew01/14/2016

Actions
Actions #1

Updated by Vince Lehman almost 9 years ago

Actions #2

Updated by Vince Lehman almost 9 years ago

  • Related to Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes added
Actions #3

Updated by Peter Gusev over 8 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.

Actions #4

Updated by Alex Afanasyev over 8 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.

Actions #5

Updated by Peter Gusev over 8 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?

Actions #6

Updated by Alex Afanasyev over 8 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.

Actions #7

Updated by Peter Gusev over 8 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...

Actions #8

Updated by Alex Afanasyev over 8 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_fetcher that gets m_validator as 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.

Actions #9

Updated by Peter Gusev over 8 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.

Actions #10

Updated by Ashlesh Gawande over 8 years ago

  • Related to Task #2965: LSAs should be segmented before they are published added
Actions #11

Updated by Nicholas Gordon over 7 years ago

  • Related to deleted (Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes)
Actions #12

Updated by Nicholas Gordon over 7 years ago

  • Blocks Task #3413: Reattempt LSA fetch based on SegmentFetcher failure specific error codes added
Actions #13

Updated by Junxiao Shi over 7 years ago

  • Category set to Utils
Actions #14

Updated by Davide Pesavento over 6 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)
Actions #15

Updated by Junxiao Shi over 6 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.

Actions

Also available in: Atom PDF