Transport support in the IoT Manager registration

[chicco785]

It would be nice to inform the iot agent manager about the supported protocols by the deployed agents. @cerfoglg can work on that (in the lib and in the iot agent manager side) what do you think?

[fgalan]

As far as I understand IOTA registrations on IOTAManager is already implemented in the library. From https://github.com/telefonicaid/iotagent-node-lib/blob/master/doc/installationguide.md#global-configuration:

• iotManager: configures all the information needed to register the IoT Agent in the IoTManager. If this section is present, the IoTA will try to register to a IoTAM in the host, port and path indicated, with the information configured in the object. The IoTAgent URL that will be reported will be the providedUrl (described below) with the added agentPath:

{
   host: 'mockediotam.com',
   port: 9876,
   path: '/protocols',
   protocol: 'GENERIC_PROTOCOL',
   description: 'A generic protocol',
   agentPath: '/iot'
}

So your proposal is to add transport information (i.e. MQTT, HTTP, etc.) as part of that process? Is my interpretation correct?

Thanks!

[chicco785]

correct :)

[fgalan]

Thanks for the clarification.

Taking into account the existing IOTAs, the transport is automatically derived from the protocol:

• IOTA-UL protocol implies MQTT, HTTP and AMQP transport
• IOTA-JSON protocol implies MQTT, HTTP and AMQP transport
• IOTA-LWM2M protocol implies LWM2M/CoAP transport
• IOTA-Sigfox implies sigfox transport
• etc.

In other words, IOTAManager only needs to know the prototocol to do the routing decission to redirect the request to the right registred IOTA. Thus, what would be the point on including transport in registration? Could you elaborate on which use case could need it?

[chicco785]

When you register a device, you need to provide also the transport protocol it will be using. Thus ideally, based on the single UL agent configuration, you can inform the IoT agent manager about the configure protocols. With this information, then you know which options of transport for a specific instance of an agent are available.

Example Scenario:

• An IoT Agent "micky" is deployed with MQTT (but not AMQP).
• You want to know (not by checking the configuration, but via an API), which are the transport supported by "micky"
• Thanks to the information about "micky", you configure the device to a supported transport, rather than one that is not configured by "micky".

[fgalan]

Regardless of this item of work, maybe it is a good idea to finalize first pending work that starting new one. in particular:

• PR https://github.com/telefonicaid/iotagent-node-lib/pull/594, LGTM from @dcalvoalonso is pending, so I guess domething is still pending.
• PR https://github.com/telefonicaid/iotagent-node-lib/pull/600, not sure about its status.

It uses to be wiser to finalize started developments than open new ones ;)

What do you think?

[manucarrace]

As far as i know, transport is already available for device provisioning. It is only needed for devices that need to implement commands.

In order to know the available transports It could be possible to extend the implementation of GET /iot/protocols in order to answer with the list of transports for each protocol.

Regards

Manuel