2

Recently, I am doing a project and I am trying to transfer a json file to the CoAP server. I put some random values in key:value pairs such as:

{
    key1: value1,
    key2: [value21, value22, value23]
}

Questions:

  • CoAP is pretty much similar to HTTP. So, like HTTP, is it possible to transfer a json file through CoAP using POST/PUT method? If it is possible, what is the recommended directory location to put the uploaded file into the server (resource directory)?

Update:

The actual file size is about to 152.8 kB.

testuser
  • 793
  • 3
  • 13
  • 35
  • leshan recommends to [use HTTP/HTTPS](https://github.com/eclipse/leshan/wiki/Using-CoAP-Block-Wise-to-transfer-large-file-%3F#what-is-our-recommended-way-) to processes large file. – testuser Dec 01 '19 at 13:20
  • 1
    Note that in general, CBOR (to which any JSON document can be losslessly converted) is more popular with CoAP, as it is easier to parse on constrained device, and often much more compact (especially when numeric keys are used in the dictionary). – chrysn Dec 01 '19 at 14:02
  • 1
    Your question about "resource directory" is unclear, please phrase that into a full question. If it's about "CoRE Resource Directory", that's largely unrelated to your quesion; it's a directory (think "index server" or "active directory", not "file system folder") in which various servers' resources are listed. – chrysn Dec 01 '19 at 14:03

2 Answers2

1

You can transfer arbitary JSON files using CoAP POST/PUT. Which directory would be writable depends fully on the server.

Note that for a file of that size, transfer times would be considerably longer than with HTTP, as packages are sent in lock-step (putting the first 1kB, response, next 1kB – whereas HTTP has a TCP window).

chrysn
  • 810
  • 6
  • 19
1

For a first shot, you may try out eclipse/californium's "simple-fileserver-example".

cf-simple-fileserver

The supports the read (GET) and uses option block 2 for that.

If you go deeper and leave the laboratory, RFC7959 blockwise may be faced several issues.

  1. coap usually assumes, that the endpoints are identified by their ip-address (and port). Though a blockwise transfer may last longer, that assumption may get broken. If the client is faced such a address change, a block option 2 (GET) may work, but for block option 1 (PUT), that would require special preparation.

  2. Though such a blockwise transfer tends to last longer, it may get paused due to temporary transmission issus. That requires then a "resumption or fail" strategy. Also here GET is much easier than PUT.

  3. Basic transmission issues on crashes. In my experience, blockwise comes with many blocks and so many MID are in use in a short period of time. If a client crashs and select a random MID on startup, the probability of an unaware MID clash is rather high. Depending on the coap servers deduplication implementation (strict according RFC7252 or advanced in awareness of that), your client may require a strategy to escape the situation, where the server retransmits unrelated messages just based on MIDs. My experience from that time was, "analyse what your get, if it smells, wait for the 247s :-)". Your client may also save the last used MID to overcome that or use a special/separate "blockwise endpoint" with disabled deduplication.

  4. IP. FMPOV some have seen the issues left to the implementation and started to fill patents. That may require attention as well.

All together: If you use bockwise for payload of sometimes some K bytes, my experience is not that bad. But if you regulary transfer more, coap may be not the right choice.

Community
  • 1
  • 1
Achim Kraus
  • 729
  • 1
  • 7
  • 11
  • Any pointers to the IP claims around block-wise? I only found [the notified ones about RFC7959](https://datatracker.ietf.org/ipr/search/?rfc=7959&submit=rfc), which is only one (from Huawei), and whatever is necessary to implement RFC7959 is covered by the IPR declaration attached to that. – chrysn Dec 03 '19 at 16:55
  • 1
    I stumbled over some some months ago using web search engines. But I didn't dig into it. I even didn't check the state (published, pending, approved etc.)e.g. https://patents.google.com/patent/WO2017040940A1/en – Achim Kraus Dec 05 '19 at 09:50