libcoap
libcoap copied to clipboard
obgm
Can not send an second observe request to the same server until it responds to a previously request
Environment
libcoap version (run git describe --tags to find it): 4.3.0
// v4.3.0-rc3-41-g25fe796
Build System: CMake
Operating System: [Windows|Linux|macOS|FreeBSD|Cygwin|Solaris|RIOT|Other (which?)] Linux
Operating System Version: [ ]
Hosted Environment: [None|Contiki|LwIP|ESP-IDF|Other (which?)] None
Problem Description
We are trying to send multiple Observations to the same server on different resources. In this case First request is going out on the wire, however the subsequent requests are getting queued in libcoap and are sent out once it receives the response to the first one.
For example: Suppose I have 4 observe requests to be sent. From application I sent all the 4 requests. And all these requests have different tokens. Because Server is sleepy in nature, it responds to the first request support after 1 minute. After 1m, the second request goes out. Now suppose again server is sleeping and responds to the second one after 1m, the third one will go out and so on.
Use case: Because we are communicating with a thread sub-system with a border router, the server only gets the requests from the border router when it wakes up, processes it, sends the response and goes into sleep mode if nothing more to process.
Had the libcoap sent all the four requests to the network, server could have got all of them in a single wakeup cycle and process them in one go. However because of queuing in libcoap, it was not possible.
Do you think it make sense not to queue the requests in libcoap being a Stack and let the application decide when to send and when to not ?
Following is a log for the same:
With CON requests, there is a RFC 7252 requirement that only one request can be active waiting for a response (NSTART is 1). If you want to send off all 4 requests (to Observe register) without delay, you need to use NON requests (not change NSTART) if you can accept the risk of your network dropping any packets.
@fun-works Can this be closed now?
Yes. It works well with increaded nstart value. Thank you so much for the support.