Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I361b83a18b4fd59be136d5f0817fc28e17e89884
Signed-off-by: Mauro Sardara <msardara@cisco.com>
|
|
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>
|
|
Change-Id: I992205148910be008d66b5acb7f6f1365770f9e8
Signed-off-by: Mauro Sardara <msardara@cisco.com>
|
|
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
|
|
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>
|