MQTT IOT AWS adapter question.

[careai-tylercone]

I was able to get this project working using the aws_protocol_adapter but since it's MQTT going to a cloud server with quotas, I reduced the message frequency by only sending when the entry/exit has changed. However, this becomes a problem when there is no activity for a while, because the connection becomes stale and starts erring out silently (i.e. says it publishes successfully, but not in actuality.) I think the problem lies in how the adapter is being used in the background. AWS claims that their IOT sdk handles keepalive pingreq's as part of the MQTT protocol, and if the right functions are called at the required rate, it does send ping requests. Now, my question, is there any way to get the deepstream pipeline to call the aws_iot_sdk's "do_work" function when idling so that it can do all of it's handling of pingreqs and such without actually sending a payload?

[mjhuria]

Hi,

You can probably modify the code in /opt/nvidia/deepstream/deepstream-5.0/sources/libs/azure_protocol_adaptor to add do_work function. I haven't checked this feature.

[oguzhanmeteozturk]

@careai-tylercone could you share where you implemented the change?

[careai-tylercone]

@ACAVJW4H I ended up implementing a dirty global variable hack in the aws_protocol_adaptor project. I exposed an NvDsMsgApiHandle in aws_nvmsgbroker.c then included it in the entrypoint of the application. I then called nvds_msgapi_do_work directly using a g_timeout_add callback function. I highly do not recommend doing it this way since I'm playing with global states in threads...

Here's the rub, do_work is supposed to be called often for the aws iot library to not get stale connections (MQTT in general wants to send PINGREQs at least once before the socket closing timeout is reached e.g. keepalive.) Deep in the deepstream sdk is deepstream/sources/gst-plugins/gst-nvmsgbroker/gstnvmsgbroker.c and it only calls do_work(L123) if user_meta is populated (L511) (increments pendingCbCount which triggers the flow in the async do_work thread.) I think it would be best to rethink the flow of the gstnvmsgbroker so that do work is called even if the user does not send any messages.

[oguzhanmeteozturk]

I ended up doing all the kafka filtering and message manupilation on a seperate consumer docker image. This seems like the most flexible solution to me.