QtCS 2017 CoAP: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
(Added my name as future reviewer for CBOR API) |
||
| Line 45: | Line 45: | ||
** Thiago's gut feeling is that making it part of QJsonDocument will make it too constrained for future uses (Example: COSE uses integer keys in maps, not strings) | ** Thiago's gut feeling is that making it part of QJsonDocument will make it too constrained for future uses (Example: COSE uses integer keys in maps, not strings) | ||
* Volunteers to work with Thiago on doing this | * Volunteers to work with Thiago on doing this | ||
** Witekio | ** Adrien Leravat (Witekio) | ||
** Frederik | ** Frederik | ||
** Shawn | ** Shawn | ||
** Alejandro Exojo | ** Alejandro Exojo | ||
Latest revision as of 18:19, 15 October 2017
CoAP Client
- Contribution consists of CoAP client
- Supports PUT/GET/POST/DELETE
- Not yet FETCH/PATCH (RFC 8132)
- Supports Blockwise transfer
- Supports Notification (QCoapReply::notified signal, QCoapClient::cancelObserve())
- Partially supports multicast
- Sending on multicast works and works for receiving one reply
- Currently does not work with receiving multiple replies
- Supports PUT/GET/POST/DELETE
- API is modelled after QNAM but does not use it
- QCoapClient, QCoapRequest, QCoapReply
- No DTLS support yet (see network discussion)
- API does support IETF-style resource discovery (multicast GET to /.well-known/core)
- QCoapClient::discover, QCoapDiscoveryReply
- API needs a little work:
- signal and parameters
- discover() should be able to send on both IPv4 and v6 multicast, without the user hardcoding anything
- building of query parameters (QUrlQuery?)
- Add a method to QCoapClient and QNetworkAccessManager: setDeleteOnFinished / setAutoDeleteReplies
- Defaults to false on QNAM, defauts to true here
- No CoAP+TCP plans yet
Testing
- Once we have CoAP server support, we can test client against server
- Inadviseable to run a CoAP server on the Qt network test server
- Network too unstable already in TCP, probably a horrible idea to use it with UDP
- We should run a local server on the testing VM
- Californium is Java
- We may need to write something with libcoap (C)
CoAP server
We will need it. For example, all OCF devices are both clients and servers.
DTLS
- DTLS support needs to be added to QtNetwork or it will be too difficult
- We just need to design it so that it will work for both the CoAP client and server
CBOR
We would like to have CBOR support in QtCore.
- Would the API be part of QJsonDocument or separate (but looking like it)?
- Thiago's gut feeling is that making it part of QJsonDocument will make it too constrained for future uses (Example: COSE uses integer keys in maps, not strings)
- Volunteers to work with Thiago on doing this
- Adrien Leravat (Witekio)
- Frederik
- Shawn
- Alejandro Exojo