Are concurrent operations supported between server and client

[fun-works]

I have implemented CoAP client and server using this library. Both are working nice till server responds to each requests immediately and after server response next requests starts. However I am facing some issues at the client end when some requests are responded lately by server.

Regarding issues that I have observed:
I have set a context in the session->app member. In the above mentioned troubled scenarios, I am observing memory corruption there at the client side. Server is running fine without any issues.
Any suggestion is appreciated.

[mrdeep1]

It is not clear from the information provided so far as to what you are trying to do and hence the issues you are seeing.

You refer to 'context' being put in session->add. Is this a coap_context_t or some other context?
Is 'context' a variable on the stack, a piece of allocated memory or a static variable? If a variable on the stack then it will no longer be valid if the function calling coap_session_set_app_data() returns.

Have you tried running the client under the control of valgrind ?

It is unclear how you are trying to do the concurrent operations.

What version of libcoap are you using ?

[fun-works]

Version: I had taken code from "develop" branch about 3-4 months back(approx.), right after the "mbedtls" support came in.

How I am doing concurrent operations:

I have TWO threads.
1. Main thread:
a. Waits for event for application for transmitting a message -> reads msg from queue -> create a new coap session -> encode the message into coap -> sends using coap_send.
b. Waits for event from the poll thread to receive from libcoap -> invokes coap_run_once(no-block)
Important Note: Above operations are sequential in the Main thread. So actually there is no concurrence for libcoap as such. But the transactions can be concurrent as I am not waiting for a response to a request before sending the next request. This is the core interfacing model and used both by my Client and Server implementations

2. Poll thread:
a. Polls for a read event using "select" for the FD got by using "coap_context_get_coap_fd()" -> Signals Main thread on a receive event.

**This is now I have made the libcoap in/out single threaded.

Issue I am facing:

At the time of sending, I am setting a application context in context->app. This is not the coap context. The memory is allocated at heap and freed after receiving a response. So, till the client receives the response before send next request, it works fine. But when server delays a response (infact for several requests), client starts showing issues. Somtimes my message_handler gets invoked twice for a single session(resulting in double free error in my handler) and somtimes I find the APP context corrupted.

My question is:

1. Is my approach correct?
2. Can I sends multiple requests at once and server may respond little later ? I know there is "separate response" for this purpose but that is more at the use case level. This delay is an operational/speed delay.

Please let me know if I need to provide more information.

[obgm]

Your approach could indeed work. As you already have found, you need to take special care when setting context->app as it is like global data in your main thread. So, when different request/response pairs overlap and you delete or change the data in one response handler this will affect everything that happens afterwards.

Regarding the delay: Not surprisingly, the code is written not to introduce additional delays. But as the response is created in your resource handler you could easily introduce a delay there (which of course, affects the timing in your entire main thread).

[mrdeep1]

At the time of sending, I am setting a application context in context->app

Do you mean context->app or session->app ? I would expect session->app.

Where do you free off the created coap_session_t used for each coap_send()?

Are you using a unique Token per coap_send() https://tools.ietf.org/html/rfc7252#section-5.3 and https://tools.ietf.org/html/rfc7252#section-5.3.1 ?

[obgm]

Did we come to any conclusion on this?