[HICN-392] Assign independent suffixes for manifests/contents

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>

1 files changed, 73 insertions, 0 deletions

diff --git a/libtransport/src/hicn/transport/utils/suffix_strategy.cc b/libtransport/src/hicn/transport/utils/suffix_strategy.cc
new file mode 100644
index 000000000..f3bcc4562
--- /dev/null
+++ b/libtransport/src/hicn/transport/utils/suffix_strategy.cc
@@ -0,0 +1,73 @@
+/*
+ * Copyright (c) 2017-2019 Cisco and/or its affiliates.
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include <hicn/transport/utils/suffix_strategy.h>
+
+using transport::core::NextSegmentCalculationStrategy;
+
+namespace utils {
+std::uint32_t SuffixManifest::getNextSuffix() {
+  uint32_t next_suffix;
+
+  switch (suffix_stragegy_) {
+    case NextSegmentCalculationStrategy::INCREMENTAL:
+      if (!nb_segments_) {
+        throw errors::RuntimeException(
+            "The number of segments in a manifest must be set "
+            "before assigning incremental suffixes.");
+      }
+      /* The current manifest's suffix + the number of segments in a */
+      /* manifest give the suffix of the last segment in the manifest. */
+      /* The next manifest's suffix is therefore that number plus one. */
+      next_suffix = suffix_ + nb_segments_ + 1;
+      break;
+
+    default:
+      throw errors::RuntimeException("Unknown suffix strategy.");
+  }
+
+  return next_suffix;
+}
+
+std::uint32_t SuffixContent::getNextSuffix() {
+  uint32_t next_suffix;
+
+  switch (suffix_stragegy_) {
+    case NextSegmentCalculationStrategy::INCREMENTAL:
+      next_suffix = suffix_ + 1;
+      if (making_manifest_) {
+        if (!nb_segments_) {
+          throw errors::RuntimeException(
+              "The number of segments in a manifest must be set "
+              "before assigning incremental suffixes.");
+        }
+
+        content_counter_++;
+        /* If the counter have reached the manifest's capacity,
+         * it means that the next suffix will be a manifest, so we skip it. */
+        if (content_counter_ % nb_segments_ == 0) {
+          next_suffix++;
+          content_counter_ = 0;
+        }
+      }
+      break;
+
+    default:
+      throw errors::RuntimeException("Unknown suffix strategy.");
+  }
+
+  return next_suffix;
+}
+}  // namespace utils