[HICN-393] Fix various issues related to manifests

The current manifest implementation is broken:

1. ManifestIndexingManager, responsible for validating manifests and
segments and retrieving the next ones, assumes that all manifests
have the same size. This assumption affects the retrieval of next
manifests which is based on the number of segments the current
manifest contains. Therefore when a non-full manifests arrives,
the computed suffix of the next manifest is wrong and refer to a
content instead, which results in an error.
2. Manifests are used to update a suffix queue which stores all
the segments listed in manifests. This queue is used to retrieve
content sequentially via a pointer indicating the next content to
fetch. When the pointer reaches the end of the suffix queue, the
consumer stops sending interests. The correct behavior would be to
wait for a new manifest which would update the queue.

This patch fixes these two issues:

1. Issue 1 was fixed by using SuffixManifest (HICN-392). This allows
to set the capacity of a manifest at the start of the consumption
instead of checking each time the size of the current manifest and
then using that (non-constant) value to retrieve the next manifests.
2. Issue 2 was fixed by passing to ManifestIndexingManager a reference
to an object capable of calling the scheduleNextInterest function,
which is then called after a new manifest is retrieved to make sure
interests for content kept being sent. This is not an optimal solution
but rather a temporary one, until the retrieval of manifests is done
at the transport level rather than in ManifestIndexingManager.

This patch also changes the order of production: manifests are now
sent before content. To do so, contents are added into a queue until
the manifest is complete.

Signed-off-by: Olivier Roques <olvrqs@gmail.com>
Change-Id: I1a1bb92ca1cf2d3c745c1b65f6c7376f916c679b

0 files changed, 0 insertions, 0 deletions