Site Tools


Infrastructure of a Plugin

A typical plugin available under bridging subdirectory is built as a shared library which is loaded by the mpm library. Please refer to the links on how to build and how to run a sample for information related to building the plugins and running them.

Lifecyle of plugin

Every plugin must have the implementation of following functions:

pluginOps (SARR)

<WRAP center round box 80%>


Upon receiving a load request by the client, an instance of the requested plugin is loaded. The state a plugin begins with is pluginCreate. Within this state of the plugin lifecycle, a plugin specific context is created and initialized. </WRAP>

<WRAP center round box 80%>


pluginCreate is followed by pluginStart. In this state, plugin is made ready to be able to service client requests by making loop control variable true. Any thread to monitor devices, if required during the course of plugin operation is spawned here. </WRAP>

<WRAP center round box 80%>


SARR stands for Scan-Add-Remove-Reconnect. The plugin continues to be in this state until a pluginStop request is received by the plugin from the client via mpm library. In this state, plugin is in service mode and accepts and performs client requests. The four basic client requests, better known as SARR operations, which are serviced in this state are:

  > pluginScan:
    This operation takes place upon receiving MPM_SCAN message. The plugin scans
    for the available devices, generates uri for each one of the found device and
    triggers a response to the client informing the client about the found device.
    Internally, it may maintain a uri to device map to keep track of scanned devices.
  > pluginAdd:
    This operation usually follows scan. Upon receiving a MPM_ADD message from
    the client along with the device uri to be added, appropriate number of resources
    as predefined in the plugin are created in discoverable mode. Metadata is also
    prepared and is cbor-encoded. Response containing metadata is sent back to the
    client to be used later for reconnect. Internally, a uri to added_device map may
    be maintained to track added devices.
  > pluginRemove:
    This operation serves client's request to delete the resources associated with
    a particular device as identified by the uri sent with the remove request. The
    iotivity resources created during pluginAdd for the device are deleted, entries
    from the maps if any are cleared and a response is triggered back to the client
    to indicate the success or failure of servicing the remove request.
  > pluginReconnect:
    This is a one-time operation which is usually triggered by the client when the
    plugin starts. The main idea behind this operation is to connect the devices
    connected in the last session in case of a crash or reboot. For each reconnect
    request, the plugin creates appropriate iotivity resource(s) and updates the maps
    (if required) to track the devices reconnected.


<WRAP center round box 80%>


Once a plugin stop request is received, the state of plugin changes from pluginOps to pluginStop. The loop control variable is made false to make the plugin stop servicing requests. All the iotivity resources created are lined up for deletion. The maps maintained(if any) are cleared and any thread spawned during pluginStart is joined for clean-up. </WRAP>

<WRAP center round box 80%>


Here, the plugin specific context created during pluginCreate is freed up and the plugin is terminated. </WRAP>

infrastructure_of_a_plugin.txt · Last modified: 2017/03/01 09:36 by ksrikara