[riot-notifications] [RIOT-OS/RIOT] net: add CoRE RD lookup client implementation (#10222)

Aiman Ismail notifications at github.com
Thu Apr 4 10:58:20 CEST 2019

pokgak commented on this pull request.

> +ssize_t cord_lc_ep_raw(const cord_lc_rd_t *rd, uint8_t content_format,
+                   char *result, size_t maxlen);
+ * @brief Look for registered resources at a RD server
+ *
+ * @param[in]  rd               the target RD server
+ * @param[out] resources        list of resources at @p rd
+ * @param[in]  limit            max number of resources prepared to receive
+ *
+ * @return number of found resources on success
+ * @return CORD_LC_NORSC if there is no resource lookup interface at @p rd
+ * @return CORD_LC_TIMEOUT if lookup timed out
+ * @return CORD_LC_ERR on any other internal error
+ */
+ssize_t cord_lc_res(const cord_lc_rd_t *rd, cord_lc_res_t *resources, size_t limit);

> This function is resource intensive. I would consider an iterative function on the collected string from coap_lc_res_raw().

Sorry, I don't quite understand here. What part of the function, do you mean, is resource intensive? Internally, it currently uses _lookup_raw, which are also used by cord_lc_res_raw, and then parses the result and put it in cord_lc_res_t.

I do however find that using iterative function on the collected string is a good idea. As clif_decode_link only decodes one link per call, cord_lc_read_res can be used as a wrapper to it to decode all the links at once and returns it to the user.

> On the other hand, I would not be surprised to see a block based response from the RD.

Block based response would be nice actually. The default GCOAP_PDU_BUF_SIZE is too small even for an RD ep with only 3 resources. Currently, I just set the buffer size bigger but using block option would solve this, I think.

I found #11056 but haven't take a deeper look at it and doesn't really know how to use the API and integrate it here yet, but as you understands it better than me, I'll keep your suggestion in mind ;)

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190404/41593ad2/attachment.html>

More information about the notifications mailing list