aboutsummaryrefslogtreecommitdiffstats
path: root/libtransport/src/hicn/transport/protocols/manifest_indexing_manager.cc
AgeCommit message (Collapse)AuthorFilesLines
2019-11-20[HICN-402] Limit in-flight interests for manifestsOlivier Roques1-2/+16
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
2019-11-14[HICN-393] Fix various issues related to manifestsOlivier Roques1-10/+17
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
2019-03-18[HICN-103] Manifest retransmissions.Mauro Sardara1-2/+33
Change-Id: I1b61c79e99bb8da471d1e284ea2a629d48b9f308 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-03-08[HICN-102] Remove warnings and compilation errors in hicn on windowsAngelo Mantellini1-2/+2
Change-Id: Ibb5d90fe35097a29fa6edccd3c7859d043888717 Signed-off-by: Angelo Mantellini <manangel@cisco.com>
2019-03-05[HICN-11] Rework on transport protocols improving components modularityMauro Sardara1-0/+217
Change-Id: I6683ec5b494238dc93591c103d25275e89b9f267 Signed-off-by: Mauro Sardara <msardara@cisco.com>