ePacket
The Infuse-IoT ePacket interface is the core communication abstraction used by the platform. By providing a secure and efficient interface, ePacket allows application logic to be written independently of particular board hardware, enabling greater code reuse and stability.
Interfaces
ePacket interfaces are the common interface through which individual packets are sent and received. Each interface typically corresponds to a single mode of a communications technology, for example UDP packets on an IP network. As a result, some technologies such can have multiple interfaces co-existing simultaneously, for example Bluetooth Advertising, GATT peripheral and GATT central.
All ePacket interfaces share a single dedicated thread for processing packet transmission and reception.
Transmission
To transmit a packet over an interface, a packet buffer must first be claimed with
epacket_alloc_tx_for_interface(). This function automatically configures the
claimed buffer with the maximum payload size of the interface. Once the packet payload
is populated, the packet transmission metadata (epacket_tx_metadata) must
be populated through epacket_set_tx_metadata().
Once constructed, packet buffers are queued for transmission through the epacket_queue()
function, which forwards the packet to the processing context. If the queueing context must be
notified of the result of transmission, a TX complete callback can be attached to individual packets
with the epacket_set_tx_callback() function.
Individual packets are treated as independent entities, with no guarantees about in-order
delivery or packet loss. Acknowledgements on individual packets can be requested with
the EPACKET_FLAGS_ACK_REQUEST flag.
Reception
Depending on the technology backend, there are several options for when packets can be received on an interface:
Reception enabled by the application through
epacket_receive():
Bluetooth Advertising
UART Serial
Reception automatically enabled due to application state:
Bluetooth GATT peripheral
Bluetooth GATT central
USB Serial
UDP
When a packet is received, the default packet handler is epacket_default_receive_handler().
This can be updated on a per interface basis with epacket_set_receive_handler().
Additional Callbacks
Applications can register for additional callbacks on an interface with epacket_register_callback().
Interface state has changed (connected/disconnected/MTU update)
Transmission on the interface has failed
Packet has been received on the interface
Security
Communications over each interface are secured through one of two mechanisms.
Infuse-IoT Security Model
Most communications interfaces are implemented using the Infuse-IoT Security Model, which uses HKDF together with the Infuse-IoT cloud public key to generate a secure key-chain per device. ChaCha20-Poly1305 is then used as an application level encryption scheme to protect individual packets.
Specification Mandated Security
For communications interfaces which have their own authentication and encryption mechanism defined as part of the specificiation (e.g. LoRaWAN), the ePacket interface can re-use those mechanisms to avoid inefficiencies (e.g. double encryption of payloads).