aboutsummaryrefslogtreecommitdiffstats
path: root/libtransport/src/hicn/transport/utils/suffix_strategy.h
AgeCommit message (Collapse)AuthorFilesLines
2020-02-26[HICN-534] Major rework on libtransport organizationMauro Sardara1-166/+0
Change-Id: I361b83a18b4fd59be136d5f0817fc28e17e89884 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2020-02-21[HICN-2] Added P2P confidential communication on hICNAlberto Compagno1-0/+1
P2P confidential communications exploit the TLS 1.3 protocol to let a consumer to establish a secure communication on an hICN name. Currently we don't support the consumer authentication (mutual authentication in TLS) and the 0-rtt session establishment. Change-Id: I2be073847c08a17f28c837d444081920c5e57a07 Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Signed-off-by: Olivier Roques <oroques+fdio@cisco.com> Signed-off-by: Mauro Sardara <msardara@cisco.com>
2020-02-12[HICN-508] [HICN-509] [HICN-506] Manifest reworkMauro Sardara1-74/+111
Change-Id: I992205148910be008d66b5acb7f6f1365770f9e8 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-11-22[HICN-411] Change how manifests are requestedOlivier Roques1-29/+18
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
2019-11-20[HICN-402] Limit in-flight interests for manifestsOlivier Roques1-0/+5
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-392] Assign independent suffixes for manifests/contentsOlivier Roques1-0/+134
This patch introduces a new class, SuffixStrategy and two sub-classes, SuffixContent and SuffixManifest which allow to independently assign suffixes to contents and manifests respectively. The produce() function in socket_producer.cc has also been changed to use them. Given a strategy and an offset (and optionally the capacity of a manifest), these classes automatically compute the correct next suffixes for both type of data (manifest or content). This removes the burden of having to manage suffixes for instance when producing or when retrieving content, and could be expanded to add more strategy in the future. Currently the only existing strategy is "INCREMENTAL": manifests with capacity N have a suffix multiple of N+1: 0, N+1, 2(N+1) etc. Contents have a suffix incremented by 1 except when it conflicts with a manifest: 1, 2, ..., N, N+2, N+3, ..., 2N+1, 2N+3... Signed-off-by: Olivier Roques <olvrqs@gmail.com> Change-Id: Ia7692d7325240de7bea6e38b668077042e5f8758 Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>