aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-11-22Merge "[HICN-411] Change how manifests are requested"Alberto Compagno3-90/+73
2019-11-22Merge "[HICN-405] Added application face delete"Alberto Compagno23-201/+446
2019-11-22[HICN-405] Added application face deleteAlberto Compagno23-201/+446
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 Compagno17-291/+1471
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-21Merge "[HICN-402] Limit in-flight interests for manifests"Alberto Compagno3-2/+25
2019-11-21[HICN-379] Add face priority support in face managerJordan Augé9-29/+99
Change-Id: Iae19e016aae833b4bc95ff6d91d51b188f398e25 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-20[HICN-404] double-free in facemgr (facemgr_list_facelets_json) + valgrind fixesJordan Augé3-3/+5
Change-Id: Id57873d3f4152af654f3bc27778d7015495597d7 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
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 Compagno17-291/+1471
Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com> Change-Id: I41641f6d27babaa1c413ecf2fe6eae0e499df97d
2019-11-19Merge "[HICN-400] fix NULL content name in PIT entry (temporary workaround)"Jordan Augé1-0/+5
2019-11-19[HICN-400] fix NULL content name in PIT entry (temporary workaround)Jordan Augé1-0/+5
Change-Id: I6a1d93a4e6beb78741d8243fc78d6ecff77b9034 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-19[HICN-399] facemgr crashes after wifi disabledJordan Augé1-1/+1
Change-Id: I8d504b1e83f79d028f2e7bbfacda2824076aa72f Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-19Merge "[HICN-397] Added punting add message for punting on udp ports"Alberto Compagno5-26/+335
2019-11-18Merge "[HICN-391] Supporting midchain as adjacencies for an ip face"Alberto Compagno1-1/+1
2019-11-18[HICN-397] Added punting add message for punting on udp portsAlberto Compagno5-26/+335
Change-Id: Ieb5faf5d01e460179028eaba92170ee95cf35edf Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2019-11-18Merge "[HICN-225] Added generic binary api for handling faces"Mauro Sardara6-158/+873
2019-11-18[HICN-391] Supporting midchain as adjacencies for an ip faceAlberto Compagno1-1/+1
Michain support is important to get a netx hop in a face whose locator is resolved in the fib through a via. Change-Id: Id0ff1522cedd5a093f242499e310a24625a3852a Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2019-11-18[HICN-225] Added generic binary api for handling facesAlberto Compagno6-158/+873
Supported messages are add, del, get, dump, get. Each message contains a face id and the expected message has different fields based on the face type. The binary api specific for ip faces is still available for compatibility but deprecated. Change-Id: I899c6cf31a56abd39ad287ea3128993857997fcb Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2019-11-18[HICN-379] Add face priority support in face managerJordan Augé1-2/+2
Change-Id: I1055e49c93e81105996a77c088fafd4b55fdc337 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-17[HICN-379] Add face priority support in face managerJordan Augé21-14/+414
Change-Id: If4f75d44fc66414a4a70135de7827f5082b97112 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-17Merge "[HICN-395] Static face/route maintainance though face manager"Jordan Augé12-87/+410
2019-11-17[HICN-378] Add a maximum number of reattempts in face manager before ↵Jordan Augé4-36/+109
entering face ignore mode Change-Id: Id6f8cc958d3c50027475d72d80eed6b65ac0996b Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-17[HICN-395] Static face/route maintainance though face managerJordan Augé12-87/+410
Change-Id: I8f2287a262412bacc50f3c89756ec9fd6ce30d33 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-17[HICN-396] Incorrect error handling order in facemgr during interface ↵Jordan Augé1-2/+4
creation causes double free Change-Id: I63f3ac8815611fe83e75edd283eabf4d721bdbac Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-15[HICN-386] Improve API error management in libhicnctrlJordan Augé6-6/+9
Change-Id: Ifab987a17255e20077242888b052e312f9e4c964 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-15[HICN-386] Improve API error management in libhicnctrlJordan Augé4-32/+34
Change-Id: I3f5e3840303265ccc3d4b864d026b63a2ccb7fdf Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-15Merge "[HICN-386] Improve API error management in libhicnctrl"Jordan Augé33-1015/+330
2019-11-14[HICN-386] Improve API error management in libhicnctrlJordan Augé33-1015/+330
Change-Id: I332e74ebcd89798c93de50ae7a20f7af8f59f54c 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-14Merge "[HICN-392] Assign independent suffixes for manifests/contents"Alberto Compagno9-42/+270
2019-11-14[HICN-375] Move cmake in ctrl/sysrepo-plugins to the main cmke in rootmashemat9-343/+16
Signed-off-by: mashemat <mhemmatp@cisco.com> Change-Id: I6c2f65e61a2f13db8261a32482336b21f07d5e45
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-12Merge "[HICN-376] Add manual connection/route setting to face manager"Michele Papalini21-205/+1317
2019-11-12[HICN-389] facemgr calls unregister_all multiple times in case of errorJordan Augé1-1/+0
Change-Id: Iaac34a53ae95b511594a5dcd6b1e614eba9ff135 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-12[HICN-376] Add manual connection/route setting to face managerJordan Augé21-205/+1317
Change-Id: I5c24f687e8e815d0e2f437ff8ce7fbb2c76e0579 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-11Merge "[HICN-383] Code cleanup"Jordan Augé2-36/+39
2019-11-08[HICN-385] fix route removal in hicnctrl, code uniformization in hicn-light ↵Jordan Augé31-332/+616
control api Change-Id: Id097368dcde993775f206623195cc5aa57b4fe12 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-05[HICN-383] Code cleanupJordan Augé2-36/+39
Change-Id: I41ca0f411053992625dec0b32ffe6a444c5bc51c Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-05[HICN-382] Misc compilation issues on MacOS (incl. Catalina specific code)Jordan Augé4-20/+20
Change-Id: I4cb2378b2e44afbaedb984409a221b2e3f0e99b4 Signed-off-by: Jordan Augé <jordan.auge+fdio@cisco.com>
2019-11-05Merge "[HICN-372] Code clean up"Jordan Augé8-26/+38
2019-11-05Merge "[HICN-380] add libhicnctrl example (create face)"Michele Papalini2-0/+154
2019-11-05[HICN-380] add libhicnctrl example (create face)Jordan Augé2-0/+154
Change-Id: I230d4cc51710fa4ce7ce24c97cd72b1fc7d1f573 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 Compagno39-526/+533
Change-Id: If3f9a7db1e1310fdc08d1003b28e5e1d4006b61e Signed-off-by: Alberto Compagno <acompagn+fdio@cisco.com>
2019-11-04[HICN-357] sysrepo plugin updatemasoud6-37/+22
Signed-off-by: masoud <mhemmatp@cisco.com> Change-Id: Idabe9d3a3b03139ad3cdb20c8c822e6dd7d4c553
2019-11-04Merge "[HICN-356] Fix uninitialized pointer"Alberto Compagno1-0/+2
2019-10-31[HICN-371] Fix invalid read reported by Valgrind when many timeouts happen.Mauro Sardara1-2/+3
Signed-off-by: Mauro Sardara <msardara@cisco.com> Change-Id: Ib31e731c02341234169bd5163eb86fe1da900e40 Signed-off-by: Mauro Sardara <msardara@cisco.com>
2019-10-31[HICN-356] Fix uninitialized pointerOlivier Roques1-0/+2
The signature verification method verify() in verifier.cc would try to initialize a pointer to the current packet's payload, which was never set in the first place. This fix calls the packet's method responsible for initializing that pointer. Signed-off-by: Olivier Roques <olvrqs@gmail.com> Change-Id: Ie5ab08036186ea4b766f6825c129ee68d01fc2b6