How to adjust maximum size of block1?

[datle1112]

I want to transfer a big file (around 3-4kb) from coap server to coap client. When the size of message goes over 1024, it will try to use the blockwise option to transfer file and it will slow down the transfer process a lot. I would like to ask is there any method that i could adjust the size to block1 so that all of my file fixes in one coap message only? (This option is available in Java library for LwM2M (Leshan))

[chrysn]

There are no real facilities in CoAP-over-UDP for larger block sizes than 1024 bytes. You can turn off block-wise transfer, though.

How you go about that depends on whether aiocoap is used as a client or as a server, and I'm a bit unsure here: You mentioned that you transfer a big file from server to client (Block2 payload), but later mention Block1.

Assuming your aiocoap program is acting as CoAP client, you would be PUTting a large payload to the server. For that, you can pass the keyword argument handle_blockwise=False) to your request call. That will bypass all the block handling code (but also require you to do any handling of blocks on your own). If your setup is different, please let me know.

I'm curious: What are you transporting over that 3-4kB is a workable message size? Does your server reassemble UDP fragmentation?

[datle1112]

Thanks for your reply. I will explain my current problem so you could fully understand what is my issue: I have about six sensors, each of them sends new data in 0.1 second. Initially, i plan to observe all of them from Leshan LwM2M demo server but i quickly found out that wasn't effective when sending a small message in a short period of time. Therefore, i decided to collect data from 6 sensors in 1 second and send all of them in only one message (payload is from 3 to 4KB) to Leshan server. However, i met another problem when it takes a really long time to transfer this message due to blockwise function. Therefore, i want to ask is it possible to send a message with payload from 3 to 4KB? (which i used to believe could be done by adjust size of "Block2" option) If not, could you recommend to me some method that could speed up the transfer process?

[chrysn]

Where are you using aiocoap in that setup? Are the sensors running Python, or are you replacing the Leshan LwM2M server with an own aiocoap implementation?

[datle1112]

I forget to mention, i run LwM2M client (coap server) on a Raspberry Pi to collect data from sensors. The library i used to build LwM2M client is based on aiocoap (lwm2mclient library). I only used Leshan demo server and didn't change any setup since i didn't have any experience with Java.

In summary, it will be perfect for me to have a solution to send a large payload in a single message that doesn't need to modify anything in Leshan server, only in Raspberry Pi.

[chrysn]

So to summarize, you are building an LwM2M client using aiocoap, and your application generates 6x10 sensor data points per second. In what I understand to be the LwM2M fashion, the LwM2M server will start observing all those six sensor resources.

Transport-wise, that looks like a case for CoAP-over-TCP to me, that will spare you all the many-ACKs-and-large-messages trouble, and none of the devices involved are as constrained as to justify the use of CoAP-over-UDP.

If all your sensors fire at once (or within a short time interval) and create six different observe notifications, Linux will make sure they wind up in a single IP packet (containing 6 CoAP messages), and that acknowledgements are sent in an efficient way.

I can't really tell you what'll happen when the sensor data saturates the network (won't happen from 6x10 values/second, but maybe if there are very many devices around). When the transmit buffer becomes full, aiocoap should do the right thing in terms of CoAP and just send only the latest data in notifications, but a) I can't vouch that it does over TCP, and b) I'm note sure that's what you or LwM2M expects. But that shouldn't become a problem for the first tests.