Polling Channel Dropping Notifications?

[tsengia]

I'm currently dealing with an issue where my IoT device becomes out of sync with my ACME CSE. I have a Flex Container with two subscriptions on it (one for a web UI dashboard, and one for the IoT devices).

The web dashboard makes HTTP PUT requests to UPDATE the FlexContainer, which triggers notifications for both subscriptions. My web UI dashboard quickly replies to these, but my IoT device takes much longer.

For infrequent updates (ie. 1 update every couple of seconds), this works perfectly. However when updates occur much more frequently, the IoT device seems to "lose" notifications. This results in the Web Dashboard displaying one state, and the IoT device being stuck in a different state.

The IoT device is not losing internet connection. It will receive some of the notifications, but eventually it makes a GET request to the polling channel and receive no more notifications, even though it clearly has missed some. This means that after a few seconds, the web UI can make another UPDATE, and the IoT device will recieve that notification properly.

Do notifications expire after a certain amount of time?
Is there any other way to ensure that my IoT device has the most recent state without resorting to rate limiting of the Web UI? Or without forcing my IoT device to constant perform GET requests on the FlexContainer?

[ankraft]

It sounds like you overload your constraint device. In my experience it might take a second form a smaller, single-core CPU device to receive and process a notification, also with long-polling. If the notification frequency is higher than the device is able to process then the device will never catch up.

To your questions: yes, notifications, like any other oneM2M request, finally will expire or time-out. ACME removes stale notifications from the polling channel. This timeout is rather short by default (10 seconds), but can be configured to be longer. You might like to add

[CSE]
requestExpirationDelta=60.0

to your configuration file to increase the request timeout for requests sent by the CSE to 60 seconds.

Another option might be to use Batch Notifications here. When enabled for a subscription notifications are not sent immediately but only when a threshold is reached, or after fixed delay, in an aggregated notification (which also needs to be confirmed, but only once per aggregation request). A nice thing with batch notification is that you can enable a "latest" option, which means that only the latest notification of a batch is sent. This might be interesting in cases when your device is interested in the latest state change and would have to ignore any old notifications anyway.

[reinaortega]

I have a question regarding the way you are getting notifications. You said: " It will receive some of the notifications, but eventually it makes a GET request to the polling channel and receive no more notifications". Maybe I am not getting the point here, but either the device gets the notifications directly from the CSE or the device makes a long polling. You cannot have both at the same time.

In addition to the solutions Andreas mentioned (batch notifications, latest notification), another solution could be to use rateLimit to setup the notifications rate that you device needs/can handle.

[ankraft]

Good idea, but rateLimit is not yet supported by ACME :(

And also, rateLimit doesn't throw away notifications, right? It is just to limit temporary peaks.

[tsengia]

I have a question regarding the way you are getting notifications. You said: " It will receive some of the notifications, but eventually it makes a GET request to the polling channel and receive no more notifications". Maybe I am not getting the point here, but either the device gets the notifications directly from the CSE or the device makes a long polling. You cannot have both at the same time.

Our device is making an HTTP GET request on the polling channel URI in order to retrieve notifications. Specifically this function is being called in a loop. Is this not the proper way to use a polling channel? I had thought that performing long polling on the polling channel is the correct way to listen for/retrieve notifications?

[reinaortega]

Yes, that's the way long polling is to be done, totally correct. I thought that you set up your device to receive notifications directly as well (if your device runs a little HTTP server for that, by setting the poa of the device AE resource, notifications will be sent directly to the device without having to do the long polling)