Re: Protecting against concurrent requests

Kishen Maloor
 

Hello,

 

> OK, thanks for confirming. It looks like the same issue would occur for GET requests as well - if

> `oc_do_get` is interrupted (before the request is dispatched, and another thread begins building a new root

> object).

 

Yes, but more generally, it would be best to synchronize every API call being made from a different thread

(i.e. different from the thread running the stack's message pump) as the APIs are not thread safe.

 

This is in fact the case for all those sample apps that present a command-line UI, and those samples

illustrate where/how this synchronization needs to happen.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@iotivity.groups.io> on behalf of Josh Milburn <josh@...>
Date: Sunday, June 7, 2020 at 4:12 PM
To: "Nash, George" <george.nash@...>
Cc: "iotivity-dev@iotivity.groups.io" <iotivity-dev@iotivity.groups.io>
Subject: Re: [dev] Protecting against concurrent requests

 

Hi George,

 

OK, thanks for confirming. It looks like the same issue would occur for GET requests as well - if `oc_do_get` is interrupted (before the request is dispatched, and another thread begins building a new root object).

 

We'll make sure that our application logic protects against this. Thanks!

 

 

 

On Fri, Jun 5, 2020 at 2:18 AM Nash, George <george.nash@...> wrote:

If you have a situation that two threads may call oc_init_post then you must prevent both threads calling oc_init_post at the same time.  You must add a mutex or some other similar guard before calling oc_init_post and then you can release it after calling oc_do_post.  The same is true for oc_init_put and oc_do_put.

 

George Nash

 

From: iotivity-dev@iotivity.groups.io <iotivity-dev@iotivity.groups.io> On Behalf Of josh@...
Sent: Wednesday, June 3, 2020 11:00 PM
To: iotivity-dev@iotivity.groups.io
Subject: [dev] Protecting against concurrent requests

 

I'm particularly interested in how the following scenario is prevented:

1. Code from one thread ("A") in the application calls `prepare_coap_request` (which in turn, calls `oc_rep_new`, resetting the current CBOR encoder state). For example, this might happen by someone calling `oc_init_post`.
2. Thread "A" sees a 'success' from `oc_init_post`, and calls `oc_rep_begin_root_object` and begins building a request body
3. Thread "A" is interrupted by higher priority thread "B" which calls `oc_init_post`. 
4. Thread "B" completes and sends request
5. Control is returned to thread "A", which continues trying to build a request body, but the data is now meaningless (since the state of `g_encoder` and `root_map` in `oc_rep.h` have been modified

Looking over the example apps, most seem to provide protection against this by ensuring that requests are not created in interrupts, and/or requests are sent via a menu driven interface. Are there further safeguards against this concurrency issue, is it actually a nonissue, or am I misunderstanding something here?


 

--

Joshua Milburn, P.E. | Senior Embedded Systems Engineer

+1 (724) 612 7788 | Skype: jjmilburn

Subscribe to Angaza’s newsletter
Twitter | Facebook | LinkedIn | YouTube

Join iotivity-dev@iotivity.groups.io to automatically receive all group messages.