3

我们正在尝试实施 oneM2M 标准，并且对 Remote CSE 和 IN-CSE 之间的通信过程有疑问。我在下面一步一步地写了我从文档中理解的内容。有些问题对我们来说不是很清楚，所以在进行任何实施之前，我需要确保一切都非常清楚。

在告诉我们从文档中了解的所有内容之前，我会问这个问题。然后我将一步一步地写出我们认为的解决方案是什么。问题是，由 IN-AE 发送的请求是针对 MN-CSE 的，IN-CSE 应该将请求重定向到 MN-CSE 或者它应该自己处理它。

首先，我们有两个完全独立的 CSE。一种是 IN-CSE，另一种是 MN-CSE，如下所示。

IN-CSE 有一个资源树

/in-cse61
   /in-cse61/csr-34
      /in-cse61/ae-1234

MN-CSE 有一个资源树

/mn-cse34
   /mn-cse34/csr-61
   /mn-cse34/ae-123456
      /mn-cse34/cnt-1
         /mn-cse34/cin-01
         /mn-cse34/cin-02
         /mn-cse34/cin-03
      /mn-cse34/cnt-2

我们暂时跳过了任何安全问题。假设 IN-AE 想要与 MN-CSE 通信，正如我们在上面的问题中所说的那样。

1- IN-AE 应该向 IN-CSE 发送发现或检索请求，告诉我所有子资源 Remote CSE。

2- 发送发现或发送检索请求之间的确切区别是什么？我们认为发现请求仅返回资源 uri，但检索请求返回确切资源的整个数据。这种方法正确吗？

3- 获得所有 remoteCSE 后，现在我知道 remoteCSE 的 ID。然后我可以向 MN-CSE 发送一个发现请求以获取其中的 AE。我们认为有两种选择：

一种。~/in-cse61/csr-34?fu=1&rty=2
b. ~/mn-cse34?fu=1&rty=2

选项 a：如果 IN-AE 只想对 IN-CSE 的资源树进行发现请求，IN-CSE 应该处理它而不将其重定向到 MN-CSE。因为 IN-CSE 已经知道 /in-cse61/csr-34 对它来说是一种有效的 RemoteCSE，但是请求路径以 ~/in-cse61 开头，所以它应该由 IN-CSE 处理。

选项 b：如果 IN-AE 想要对 MN-CSE 的资源树进行发现请求，那么 IN-CSE 可以通过查看请求路径的 /mn-cse34 部分来了解它与 RemoteCSE 相关，因为它不以 IN 开头-CSE 的资源 ID。

所以 IN-AE（例如智能手机）应该以某种方式决定哪个 CSE 应该处理请求？我们觉得有什么不对吗？

---------------------已编辑---------------------------- ----------

在此处输入图像描述

我检查了应用程序开发指南 TR-0025 http://www.onem2m.org/application-developer-guide/architecture的架构

根据这个示例，智能手机 (IN-AE) 可以通过 IN-CSE 控制 Light#1(ADN-AE-1)。

在注册和初始资源创建过程完成后，系统准备好发现并控制灯。

GET /~/mn-cse/home_gateway?fu=1&rty=3&drt=2 HTTP/1.1
Host: in.provider.com:8080

虽然中间节点 CSE-ID 和中间节点 CSEBase 名称用于 HTTP 请求 url，但主机寻址到 IN-CSE。这意味着，从 IN-AE 发送的发现请求，首先由 IN-CSE 处理，然后将其重定向到 mn-cse。然而，您告诉我相反的说法“<em>检索或发现通常仅限于托管 CSE 的资源，不会自动遍历远程 CSE。”。

在 TR-0025 中，给出的示例显示为常见场景。同样在 TR-0034，实际上它正在遍历请求，如图所示。

在此处输入图像描述

4

1 回答 1

2

你的问题有很多地方需要解决。

首先，oneM2M 中没有名为“IN-AE”的特殊实体。这只是 oneM2M 的TR-0025 中用于连接到 IN-CSE 的 AE 的名称：Light control using HTTP binding developer guide。应用程序实体实际上可以通过相同的协议 (mca) 连接到 IN-CSE 或 MN-CSE，尽管可能存在专门设计用于在一个特定 CSE 上工作的 AE。

关于您的第 2 点，检索和发现请求之间的区别
：检索请求针对的是要检索它的资源。例如，发送到容器资源/mn-cse34/cnt-1（来自您的示例）的检索请求将检索容器资源本身及其属性。
发现请求也是针对资源的，从技术上讲，它看起来很像正常的检索请求。但除此之外，您还提供过滤条件和发现结果类型。例如，一个发现请求发送到同一个容器资源/mn-cse34/cnt-1可能会从该容器资源返回对ContentInstances的所有引用。根据过滤器和结果类型，您可以获得完整资源或仅引用它们。

请查看 oneM2M 的规范TS-0001 功能架构，第10.2.6 节发现和第8.1.2 节请求以获取完整说明以及发现请求的可能参数列表。

关于您问题的第 1 点和第 3 点：我不知道您的 AE 想要解决什么，但它应该具有内置数据结构的概念。以结构化和统一的方式组织数据是个好主意，例如，通过使用Containers、FlexContainers、Groups等。这样应用程序不需要浏览 CSE 的整个资源树，随着时间的推移可能会变得非常大。当然，它可能是一个通用的应用程序，需要遍历一个更大的、先验的未知结构。在这种情况下，应用程序可以使用发现请求获取相关资源。请注意，您还可以对资源的元数据进行发现，例如标签、日期和时间等。这可能有助于减少结果集。

检索或发现通常仅限于托管 CSE 的资源，不会自动遍历到远程 CSE。一个例外是已宣布的资源。这些资源被宣布给远程 CSE，在那里它们获得一种“影子”对应物，它们为您的应用程序提供一些有关资源状态以及如何检索它们的信息（通过链接属性）。但是，如果您真的想访问远程 CSE 并且您的应用程序有权这样做，则pointOfAccess属性会为您提供远程 CSE 的地址。

但如前所述，通常您的应用程序 (AE) 连接到单个 CSE。在该 CSE 上托管 AE 的所有资源或 AE 有权访问的资源。还要记住，AE 需要在 CSE 上获得权限（通过AccessControlPolicy）才能访问资源。

更新

也许我需要详细说明如何使用远程 CSE。现在忽略已宣布的资源，您的“IN-AE”可以访问远程 CSE 上的资源有两种可能性：

  • 您可以向IN-CSE 中的远程 CSE 资源发送检索、更新等请求。然后这些请求通过IN-CSE 和 MN-CSE 之间的Mcc连接转发到真正的“mn-cse”实例。这样做的好处是“IN-AE”不需要关心如何直接连接到MN-CSE“mn-cse”（例如，可能有防火墙等来保护MN-CSE）。
    如果您查看 TR-0025 ( http://www.onem2m.org/application-developer-guide/implementation/content-instance-retrieve )示例中的 HTTP 请求，您可以看到这一点
    GET /~/mn-cse/home_gateway/light_ae1/light/la HTTP/1.1
    。这个 http 请求的接收者是IN-CSE。但是，如您所见，它以远程 CSE的ContentInstance为目标mn-cse。
  • 如果您确实需要直接访问远程 CSE，例如出于性能原因，那么您的“IN-AE”可以检索pointOfAccess属性并直接访问远程 CSE“mn-cse”。在这种情况下，“IN-AE”实际上变成了远程 CSE“mn-cse”的 AE，并且需要知道如何连接到它。
于 2019-01-31T19:21:29.243 回答