Cloud COAP-Client TCP Issues

[KCrawford]

I'm building a COAP client using the Nordic nRF9160DK cloud coap-client example code as my base. I have the UDP version working great. But I'd like to convert to TCP.. I was hoping it would be a simple change to the socket just the addrinfo and socket creation calls, and turning off polling (since it's stream oriented) The first packet appears to send successfully. And the 2nd attempt always fails with a -128 error. I know COAP is more adapted to packet vs stream protocols. But I believe it is designed to work with either. Can you assist with resolving this issue. I will post some screenshots to show the mods I made for TCP.

[KCrawford]

Here are some screenshot of how I configure the sockets and the logging out. BTW, I'm using SDK 1.7.1 and Segger

[KCrawford]

Well, for some reason, I can't drag-n-drop the screenshots here. So I'll just paste the code. Ugh!

int err;
struct addrinfo *result;
struct addrinfo hints = {
.ai_family = AF_INET,
#ifdef USE_UDP
.ai_socktype = SOCK_DGRAM

#else
.ai_socktype = SOCK_STREAM
#endif

-------

static int client_init(void)
{
int err;

#ifdef USE_UDP
sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
#else
sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
#endif

[Achim Kraus]

Using CoAP over UDP is specified in RFC 7252, CoAP over TCP in RFC 8323. It uses different message formats (e.g removed MID, though the transmission is left to TCP, added length, which must be handled above TCP).

AFAIK, libcoap offers a up-to-date implementation. If you want to test CoAP over TCP you will also require a server. eclipse/californium only offers a experimental implementation, which was never updated according the final RFC 8323. So that sandbox will hardly work, you need an other one.

May I ask, why you try to use CoAP over TCP?

In too many cases you lose the advantages of CoAP (less ip-messages, very efficient, very reliable, and with DTLS CID (upcoming RFC 9146 ) all that with true e2e security.

[KCrawford]

This is my first COAP project, so not a lot of experience. The reason we would like to use TCP is primarily due to payload size. We have multiple sensors sampling at 200HZ.And we transmit at 2HZ. And the payload size is about 1730 bytes. Apparently, that is too large for Zephyr's UDP implementation. But we overcame that issue with LZ4 compression. So we were hoping switch to TCP would give us some size and speed advantages. And we do have a server that supports TCP/TLS.

So I'm seeing Zephyr's COAP Lib only supports these RFC. I guess that mean Zephyr doesn't support COAP/TCP?

• RFC7252: The Constrained Application Protocol (CoAP)

• RFC6690: Constrained RESTful Environments (CoRE) Link Format

• RFC7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP)

• RFC7641: Observing Resources in the Constrained Application Protocol (CoAP)

[Achim Kraus]

Generally, I'm not sure, if operating a CAT-M1/CAT-NB modem at 1k/s is a good idea. That depends on your SIM card contract and battery size. And I guess, it only works for CAT-M1.

If RFC8323 is not supported, you can't use that standard for CoAP over TCP. You may try to fiddle it your own way (e.g. prepend the length ahead with 2 bytes and decode them when reading), but I'm not sure, if that is good idea.

If it's just the payload size, there are two ways to go:

- RFC7959 or

- send the data in smaller packages little more frequently. If your server is fast enough, you may use NSTART-2 (means you may have two requests in flight), though RTT is in CAT-NB not that fast. (Maybe CAT-NB isn't fast enough at all.)

Finally, even though I'm a real fan of CoAP,I'm not sure, if other protocols would fit better.