Hello! See my comments: Ondrej Tomcik :: KISTLER :: measure, analyze, inovate
From: iotivity-dev@lists.iotivity.org <iotivity-dev@lists.iotivity.org> On Behalf Of yitzc...@coapp.co.il Sent: Dienstag, 30. Oktober 2018 18:11 To: iotivity-dev@lists.iotivity.org Subject: [dev] Maintaining a connection from Coap devices to the iotivity cloud In a production iotivity cloud setup, with many Coap devices connecting to the cloud, it is very important to make sure that coap devices maintain a connection to the iotivity cloud as much as possible. Otherwise, after a device disconnects, it is inaccessible unless a manual operation is performed, which is not relevant in a a large scale setup. The PING/PONG mechanism seems the most relevant in this context, I would like to hear your opinions on the following questions/issues: 1. The cloud exposes an API as to how often the PING/PONG should occur. The default today is 1,2,4,8 minutes. There is no way to configure less than a minute. I would like to be able to configure in values measured in seconds vs minutes. What are your thoughts on this? Configuration shouldn’t limit you to minutes. That’s clear. We wanted to change it but it would be bit complex change because of backwards compatibility. And, it does not make sense because keep alive resource (ping/pong) which is in the IoTivity cloud implementation is not part of the specification. In the new cloud implementation, we will use CoAP signaling directly, which you will be able to configure in seconds of course. But, in production, keepalive in seconds might be overkill. Assume you have 1000 devices. What do you need such an often keep alive exchange for? 2. If a Coap device cannot ping the cloud, it closes the connection. I want to be able to reinitiate the connection from the device when this happens. There is no API that updates the application if the PING/PONG failed. Should there be such API? How about having an option in the iotivity code to automatically try to connect instead? There is an API for that. https://github.com/iotivity/iotivity/blob/51a9a41483d5e79292a8e4ed3d5b79761488d158/resource/src/CAManager.cpp#L97 3. Today, the devices begin sending a ping request, together with the sign-up/sign-in request. This means that the cloud answers to ping requestfor unauthenticated devices. This add overhead of managing devices that have not finished their sign-in process yet, and also can give a device a false sense that it is connected, even though for some reason it is not signed in. What are your thoughts on having the ping being initiated only once the device has signed in? Moreover, what about having the cloud only provide a proper POING request to a PING request only if the device is signed in? It will be solved through CoAP signaling. No resource at all, nothing to do with sign-in/up. 4. In the OCF CoAP Native Cloud 2.0 document found here: https://wiki.iotivity.org/coapnativecloud it says the following: "OCF CoAP Gateway has to ping the device in the configured time, if pong is not received after the configured number of retries, then the connection with the device is closed and device is set as offline" In this model the gateway ping the devices, as opposed to the current implementation where the devices ping the gateway/cloud. I think this can put a very heavy load on the cloud to manage this. What are your opinions about this? What kind of load? Again, it’s not resource based keep alive. Resource is an unknown terminology in this context. It’s protocol based, for gateway it’s no overhead. It’s just global configuration, so each established CoAP connection is “signaled”. Any other thoughts on this issue of maintaining a live connection between the devices and the iotivity cloud? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9976): https://lists.iotivity.org/g/iotivity-dev/message/9976 Mute This Topic: https://lists.iotivity.org/mt/27796570/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
