commit | 0dd1daae2dffb1ebdc88e751766effb29c0c2288 | [log] [tgz] |
---|---|---|
author | Christopher Collins <ccollins@apache.org> | Tue Jul 23 17:32:36 2019 -0700 |
committer | ccollins476ad <ccollins476ad@gmail.com> | Mon Jul 29 09:51:49 2019 -0700 |
tree | 64ea22f9eed57e6cfaeafbf0200e3a7f44822877 | |
parent | 0dcb0de1c9776010fbf56d598232b8fb88892082 [diff] |
nmxact: API change for CoAP operations This commit changes the CoAP functions in the `sesn` interface. In particular, it replaces the old API with three low-level functions: // Creates a listener for incoming CoAP messages matching the // specified criteria. ListenCoap(mc nmcoap.MsgCriteria) (*nmcoap.Listener, error) // Cancels the CoAP listener with the specified criteria. StopListenCoap(mc nmcoap.MsgCriteria) // Transmits a CoAP message. TxCoap(m coap.Message) error Helper functions that combine these operations in useful ways are implemented in `sesn/sesn_util.go`. Prior to this change, `sesn` contained only two CoAP functions: TxCoapOnce(m coap.Message, opt TxOptions) (coap.COAPCode, []byte, error) TxCoapObserve(m coap.Message, opt TxOptions, NotifCb GetNotifyCb, stopsignal chan int) (coap.COAPCode, []byte, []byte, error) Both of these functions performed transmit followed by a blocking receive. There were two issues with these functions: 1. Lots of duplicated logic in each `sesn` implementation. 2. Some forms of application layer security are not possible. Re: 2- for example, say secure notifications are implemented as follows: Notification is encrypted and wrapped in a second, unencrypted, CoAP notification. The outer message always specifies the same resource and has an indeterminate token. To receive these notifications, the application needs to set up a permanent listener for the secure resource. This listener needs to be created independently; it should not be paired with a transmit operation. To make this possible, the "listen" operation needs to be a standalone function. More generally, an interface with low level functions leads to less code duplication and a better design.
Newt Manager (newtmgr) is the application tool that enables a user to communicate with and manage remote devices running the Mynewt OS. It uses a connection profile to establish a connection with a device and sends command requests to the device. The newtmgr tool documentation can be found under /docs which are published at http://mynewt.apache.org/latest/os/modules/devmgmt/newtmgr.html
Build the newtmgr tool as follows:
apache-mynewt-newtmgr-1.3.0
directory to $GOPATH/src/mynewt.apache.org/newtmgr
cd $GOPATH/src/mynewt.apache.org/newtmgr/newtmgr
go build