Age | Commit message (Collapse) | Author | Files | Lines |
|
This patch introduces a new way of requesting manifests such that
all the segments they contain fill the current transport window.
When a manifest (M) is received, we compute
L = last_segment_requested + current_window_size.
L is therefore equal or greater than the last segment of the
current window.
Then we compare L to the suffix of the next manifest that will
be (potentially) requested.
If L > next_manifest, it means that the last segment of the window is
greater than the first segment contained in the next manifest.
Therefore we request manifests until L <= next_manifest, ie until the
manifests would cover the entire window.
If L <= next_manifest, then all the manifests that were requested
already cover the window, so there's no need to request more. However
if the next manifest immediately follows the current one (M), we still
need to request it so that the content suffix queue is correctly
updated.
Signed-off-by: Olivier Roques <olvrqs@gmail.com>
Change-Id: I71a5a0031cd783277d0aa59fd68d5d7bf64fe6ae
|
|
Currently, interests for manifests are sent independently of the
transport protocol. When receiving a manifest, interests for next
manifests are sent until the next window would be full of data
segments.
But there is no limit on the number of interests for manifests that
can be sent. After a while, the interest input buffer in the
producer's side is full of them and cannot satisfy the requests
quickly enough. This results in a large drop of bandwidth on the
consumer side. This patch allows to limit the number of in-flight
interests for manifests.
Signed-off-by: Olivier Roques <olvrqs@gmail.com>
Change-Id: Ic497bd55fd92233e4b47b04635fb9bf75506375e
|
|
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
|
|
Change-Id: I1b61c79e99bb8da471d1e284ea2a629d48b9f308
Signed-off-by: Mauro Sardara <msardara@cisco.com>
|
|
Change-Id: Ibb5d90fe35097a29fa6edccd3c7859d043888717
Signed-off-by: Angelo Mantellini <manangel@cisco.com>
|
|
Change-Id: I6683ec5b494238dc93591c103d25275e89b9f267
Signed-off-by: Mauro Sardara <msardara@cisco.com>
|