Giters

obgm / libcoap

A CoAP (RFC 7252) implementation in C

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Doesn't libcoap support concurrency?

MrHulu opened this issue · comments

commented

libcoap doesn't seem to support concurrency, am I using it incorrectly?
I need help, I need help, thanks a lot!

Environment

  • libcoap version (4.3.1):

  • Build System: [CMake]

  • Operating System: [Windows]

  • Operating System Version: [10.0.22621.0]

  • Hosted Environment: [None]

Problem Description

libcoap doesn't seem to support concurrency, am I using it incorrectly?

Test

I tested and modified the libcoap-minimal project.
The modifications are as follows:

  • in server.cc, I added new resources
  • In client.cc, the program will run and send two requests to the server at the same time, a request and b request.

Then I made the following two attempts:

  • Running client only, the implementation of client.cc sends both a and b requests, but I captured the coap communication information in wireshark tool and found that only a request was sent, and it kept retransmitting five times (there is a strange phenomenon here, the default value of CoAP maximum retransmit is 4, but it retransmits five times! ) . After 5 retransmissions, the b request will be sent.
  • Run server first, then run client, client.cc implementation is to send a and b two requests at the same time, but in the wireshark tool to capture the communication information of the CoAP found that after the a request is sent to receive the server's response to the a request, the b request is only sent ....

This is obviously not consistent with udp, udp should be concurrent. I look forward to your reply!

commented

What we need to look at here is the CoAP protocol (RFC7252 and understand its rules as it runs over (in this case) UDP,

Actually, the packet is (correctly) sent 5 times, the initial transmit plus 4 re-transmits gives a total of 5.

As you are sending packets of type CON (confirm-able), the rules are RFC 7252 4.7 Congestion Control where any outstanding request has to be acknowledged (or has a timeout failure and the request cancelled) before the next request can be sent as defined by the variable NSTART. It is not recommended that you change the value of NSTART as per RFC 7252 4.8.1 Changing the Parameters. So, sending "b" has to be delayed until "a" has been responded to, or has timed out with no response.

If you were to send the packets of type NON (non-confirm-able), then you are not subject to NSTART. In theory, the rate of which these can be sent is based on PROBING_WAIT if responses are not received. libcoap does not currently enforce PROBING_WAIT, but may do in a future release.

commented

I'm sorry. I don't see congestion control as a mechanism. I see!
By the way, do you have a plan for when you will release the latest version of the.