why coap client delay

[daohu527]

When the coap client frequently receives data(which use a observe mode), sending data may be unsuccessful(get\put). What is the reason?

below is the debug log

\x0A\x013\x19\xF4\xA4Z\x0B\x0A\x1D\xD8A"\x0F\x0A\x011\x10\x00\x1A\x08\x08\x06\x10\x00\x18\x02 \x01(.H\x0AP\x05'
Apr 12 19:00:03.644 DEBG ** 10.30.194.243:35401 <-> 10.30.194.244:8751 UDP : tid=57473: delayed
Apr 12 19:00:03.644 DEBG ** 10.30.194.243:35401 <-> 10.30.194.244:8751 UDP : tid=57474: delayed

[mrdeep1]

It would be helpful if you could tell us the version of libcoap you are using.

The primary reason for UDP packets getting "delayed" is that if the packet type is Confirmable and a previously sent Confirmable packet has not yet been ACK'd by the peer. In other words, if a Confirmable request's response is outstanding, no further Confirmable packets can be sent - hence the delay (Congestion Control) . See https://tools.ietf.org/html/rfc7252#section-4.7 . Updating NSTART is NOT the right answer/fix here.

This may be caused by a coding error - possibly fixed in a later version of code) - looking at more of the debug logs should help you here - in particular the actual PDUs being sent / received.

[daohu527]

Thx for your reply! the version is

project(
  libcoap
  VERSION 4.3.0
  LANGUAGES CXX C)

additional

I subscribed to 2 observation topics. When only one message is pushed, sending and receiving are fine. If I enable another push(client observe) (20HZ), both topics can receive messages, but message sending will always be delayed (maybe at first is good, this phenomenon is not very stable), and the frequency of sending(client get) messages is very low

How can I print out the PDU debug msg?

[mrdeep1]

Your code is reasonably up to date.

If the logging level is set to LOG_DEBUG (which it appears to be from your logging output snippet). then each PDU is decoded and printed out. The output line will start with v:1 and look something like v:1 t:CON c:GET i:4599 {} [ ]

I assume that the 2 observations are in the same client, and that each observation is using its unique token. I also am assuming that the application is not expecting libcoap to be multi-threaded. Correct?

[daohu527]

I assume that the 2 observations are in the same client, and that each observation is using its unique token. I also am assuming that the application is not expecting libcoap to be multi-threaded. Correct?

Yes, because libcoap does not support multi-threading, so I use a shared client, two threads subscribe to data from different topics through one client.

One observe topic can receive data and send data well. If I start to send another observe topic, both topics can receive messages, but the client send message will always be delayed (maybe at first is good, this phenomenon is not very stable).

log

I will print the log and display more detailed information, because there is a topic that contains more frequent messages, so I may need to organize the log

[mrdeep1]

Providing access to the common client logic is suitably (mutex) protected (both sending requests and receiving responses) then multiple topic threads should be fine.

I am assuming that doubling the rate of a single client does not throw up any issues.

Are you using a separate coap_session for the second topic - if so, NSTART applies to each coap_session separately so there should not be overlapping confusion there. If you are multiplexing the traffic over the same coap_session, then it is possible that one of the topics just gets ahead in the sending, causing the other thread not to get equal share of outputting.

[daohu527]

there's a server singleton called by multiple threads

client <--- observe topic1  server    thread1
       <--- observe topic2  server     thread2
       ---> coap_send       server     thread1

[mrdeep1]

My suspicion it that the server is not multi-thread safe. For example, both server threads cannot individually call coap_io_process() or coap_resource_notify_observers().