aboutsummaryrefslogtreecommitdiffstats
path: root/libtransport
AgeCommit message (Collapse)AuthorFilesLines
2020-02-12[HICN-508] [HICN-509] [HICN-506] Manifest reworkMauro Sardara40-1038/+1714
Change-Id: I992205148910be008d66b5acb7f6f1365770f9e8 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2020-02-12Merge "[HICN-512] documentation bundle using sphinx"Mauro Sardara2-134/+0
2020-02-12[HICN-512] documentation bundle using sphinxLuca Muscariello2-134/+0
Change-Id: I1dcbca50f7406ef2714683547b6bb32463e1baf8 Signed-off-by: Luca Muscariello <muscariello@ieee.org>
2020-02-12[HICN-513] fix uninitialized batching parameter in libtransport's rate ↵Jordan Augé1-1/+2
estimation Change-Id: I5e3855439994dea453d68cda446b6756240265a9 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2020-02-11[HICN-511] Added android log for libhicntransportMauro Sardara1-6/+4
Change-Id: I566939e02d7f2c8be6be9665d32c09f4737f69e1 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2020-02-05Merge "[HICN-503] correctly compute drop probability in RAAQM"Alberto Compagno1-1/+2
2020-02-05Merge "[HICN-501] Change calculation of next reassembly segment when ↵Michele Papalini4-39/+57
manifests are enabled"
2020-02-05[HICN-503] correctly compute drop probability in RAAQMmichele papalini1-1/+2
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: I1b74a88c4d46aae178599f43ac6f223b29d4dfc5
2020-02-05[HICN-502] fix min_filter max sizemichele papalini1-1/+1
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: I108240376b67c221d440f43496a17513b89db0a3
2020-02-04[HICN-501] Change calculation of next reassembly segment when manifests are ↵Olivier Roques4-39/+57
enabled When manifests are enabled, the current way of computing the next reassembly segment is broken: if manifests are received out of order, which can happen if a interest for a manifest timeouts, reassembly will also be out of order. This patch makes uses of the SuffixContent class introduced in HICN-392 to correctly compute the index of the next segment to reassemble. Change-Id: I2784f3da544fef7b48a110dd6c233657610f44b8 Signed-off-by: Olivier Roques <oroques+fdio@cisco.com>
2020-02-03Merge "[HICN-489] Add iOS support to hicn stack"Jordan Augé2-2/+2
2020-02-03[HICN-489] Add iOS support to hicn stackAngelo Mantellini2-2/+2
Signed-off-by: Angelo Mantellini <angelo.mantellini@cisco.com> Change-Id: I8fa8c4eaa3218eb4be46f713b15ab789c6930aa0
2020-01-31[HICN-499] RAAQM: do not reinitialize window at every call of consume.Mauro Sardara1-1/+0
Change-Id: I557164a31997574cbf93b0612cdd87e21be76c74 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2020-01-30[HICN-492] Initialization of vapi_ctx_t before calling vapi_safe_connect()Alberto Compagno2-12/+12
Change-Id: I26aeaffe40cfff460d9780319e54fcb74114cee4 Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2020-01-30[HICN-445] Update to vpp 20.01Alberto Compagno1-13/+1
Change-Id: I19a442080b6ca8b0477a8f92f161282288c395ee Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2020-01-27[HICN-488] Adding lock to vapi calls and manage vapi_connect in order to ↵Alberto Compagno5-41/+75
connect only once. - Added library to hicn-plugin called safe_vapi that takes care of handling concurrent calls to the vapi. - Removed dependency of libhicnctrl from libtransport and added dependency to safe_vapi. - Added dependency to safe_vapi on libhicnctrl Change-Id: Ie49e8319f64a50e7ed6a56e041db977c3b184cc5 Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2020-01-20[HICN-479] Fixed dependency on libhicnctrl-memif in libtransport-memif deb ↵Alberto Compagno1-2/+2
and rpm package Change-Id: I89e24f923a67192c2c57dbbd510c65a6b5a49457 Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2020-01-09[HICN-471] Fix wrong callback check in RAAQMOlivier Roques1-1/+1
The wrong callback is null-checked before it is used in RAAQM. Signed-off-by: Olivier Roques <oroques+fdio@cisco.com> Change-Id: Id602453ad18d0297663b7cef66daa58cc5c0891a
2019-12-20[HICN-466] expose rtt stats to appliaction in rtc transportmichele papalini1-0/+1
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: If7af2154f5054a475521bf84c8d455ad3058bbb9
2019-12-19[HICN-463] Initialize memory before sending message to hicn-light-forwarderMauro Sardara1-1/+1
Change-Id: I4cfd1d45fb754d9efb71ff80ae97ca4fe27e47a2 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-12-11Merge "[HICN-430] Rework on CMake"Luca Muscariello1-12/+12
2019-12-10[HICN-430] Rework on CMakeMauro Sardara1-12/+12
Change way targets are defined: each project defines targets. Fix project BUILD flags Add build-extras bash script Rework build tree of extras folder, using ExternalProject_Add Change-Id: I82fa29896e54c8a033490eba013c3f0431bec9d0 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-12-06[HICN-437] concurrency problem in rtc producer socketmichele papalini2-3/+3
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: I629914f48e00814796f16b201e03549e9c7941bd
2019-12-04Merge "[HICN-433] fix and tune parameters in rtc transport"Mauro Sardara1-2/+2
2019-12-04[HICN-433] fix and tune parameters in rtc transportmichele papalini1-2/+2
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: Ib67d395e0c7c4ac4c11dabe44cbde417faa70e20
2019-12-04[HICN-427] Producer and consumer socket created with vapiAlberto Compagno15-986/+409
Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I44142385b191b4c9b5c4bb418bfbd06a5e102eec
2019-12-04[HICN-428] Creating libctrl deb and rpm packages specific for hicn-pluginAlberto Compagno2-3/+4
Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I2460276eb400777105d3351dffdaf8452f01c51f
2019-12-02Merge "[HICN-425] RTC min window"Alberto Compagno1-3/+0
2019-12-02[HICN-425] RTC min windowmichele papalini1-3/+0
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: Ic75e11dcf43b7ed947a8f577d9aa5d345d5662ee
2019-12-02[HICN-426] Add isRunning API to consumer and producer socket.Mauro Sardara3-0/+9
Change-Id: I5a144f804b87c3575f24c57ba5086136ec02efcd Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-12-02Merge "[HICN-425] RTC min window"Alberto Compagno2-2/+8
2019-12-02[HICN-425] RTC min windowmichele papalini2-2/+8
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: Ieb41ffff61ed4341dc9aacb58d3e7c397e72fc41
2019-11-29[HICN-423] Handle exception of producer socket thrown upon socket disposing.Mauro Sardara1-1/+7
Change-Id: I2458d054150ca307cf7ac0391f7698ebf2e7466e Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-11-25Merge "[HICN-406] Adding face deletion on the hicn-plugin when the ↵Mauro Sardara4-7/+95
corresponding socket is destroyed"
2019-11-22[HICN-413] rtc client improvementsmichele papalini2-9/+20
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: Ia23dee91776ccaa0bdf667eefc850e298f966cec
2019-11-22Merge "[HICN-411] Change how manifests are requested"Alberto Compagno3-90/+73
2019-11-22[HICN-406] Adding face deletion on the hicn-plugin when the corresponding ↵Alberto Compagno4-7/+95
socket is destroyed Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I09268dc5ae2ad465b4a4f68607732c0d3f48e62e
2019-11-22Merge "[HICN-405] Added application face delete"Alberto Compagno2-2/+4
2019-11-22[HICN-405] Added application face deleteAlberto Compagno2-2/+4
Added two new messages in the binary api: - hicn_api_face_cons_del to delete a consumer face - hicn_api_face_prod_del to delete a producer face Added the corresponding commands in the vpp_api_test for debugging and testing Reworked the cache policy structure to add a new function that flash the content store from the content coming from the destroyed producer face. This is required since the CS while each producer face has its own lru list. Removing only the producer face without flushing the CS from the content coming from the producer face will lead to a segfault in case there is a hit in the CS as the lru no longer exists and it won't be possible to update the head of the lru. Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I8776c86952d50900aa504dd22aec521ed25c1dae
2019-11-22[HICN-411] Change how manifests are requestedOlivier Roques3-90/+73
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-22Merge "[HICN-394] Add route commands add, list, del for the hicn-plugin"Alberto Compagno2-3/+9
2019-11-22[HICN-410] reduce sentinel timer aggressivenessmichele papalini1-2/+2
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: I538d8266912fea244505e4d2ceccef0dd9a242bc
2019-11-22[HICN-409] remove race condition in rtc procuder socketmichele papalini1-2/+4
Signed-off-by: michele papalini <micpapal@cisco.com> Change-Id: Ifdc5d912b8687bae3da78fadb05524d78e767f5a
2019-11-20[HICN-402] Limit in-flight interests for manifestsOlivier Roques3-2/+25
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-20[HICN-394] Add route commands add, list, del for the hicn-pluginAlberto Compagno2-3/+9
Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I41641f6d27babaa1c413ecf2fe6eae0e499df97d
2019-11-15[HICN-386] Improve API error management in libhicnctrlJordan Augé1-1/+1
Change-Id: Ifab987a17255e20077242888b052e312f9e4c964 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-14[HICN-393] Fix various issues related to manifestsOlivier Roques7-20/+50
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-11-14[HICN-392] Assign independent suffixes for manifests/contentsOlivier Roques9-42/+270
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>
2019-11-08[HICN-385] fix route removal in hicnctrl, code uniformization in hicn-light ↵Jordan Augé3-22/+23
control api Change-Id: Id097368dcde993775f206623195cc5aa57b4fe12 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-04[HICN-262] Fix binary api to prevent byteswapping of ip addresses in vapiAlberto Compagno13-85/+91
Change-Id: If3f9a7db1e1310fdc08d1003b28e5e1d4006b61e Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>