Hello Max, I was on a business trip and was not able to reply earlier. Sorry.
See my comments Ondrej Tomcik :: KISTLER :: measure, analyze, inovate From: Max Kholmyansky <max...@gmail.com> Sent: Sonntag, 11. November 2018 12:24 To: Tomcik Ondrej <ondrej.tom...@kistler.com>; Yitzchak Bernstein <yitzc...@coapp.co.il>; iotivity <iotivity-dev@lists.iotivity.org> Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud On Wed, Oct 31, 2018 at 9:52 PM Ondrej Tomcik <ondrej.tom...@kistler.com<mailto:ondrej.tom...@kistler.com>> wrote: ________________________________________ From: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> [iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>] on behalf of yitzc...@coapp.co.il<mailto:yitzc...@coapp.co.il> [yitzc...@coapp.co.il<mailto:yitzc...@coapp.co.il>] Sent: 31 October 2018 19:16 To: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: Re: [dev] Maintaining a connection from Coap devices to the iotivity cloud On Wed, Oct 31, 2018 at 03:26 AM, Ondrej Tomcik wrote: What do you need such an often keep alive exchange for? If a connection breaks, the Coap device will no longer receive requests. Therefore I need it to try to reconnect as soon as this happens. The only existing mechanism I am aware of telling if the connection is broken is via the PING/PONG mechanism. -> yes, thats what ping pong is for. In case the connection was not closed gracefuly, you are waiting for a tcp timeout. If you want to know if the device is online, thats the only way. But you have to consider your requirements, how accurate information about the device status has to be? Additionaly, you should introduce timeouts for your requests. So not only ping the device every 5 seconds, what is actually a bad idea, but handle also request timeouts and flag the device as not reachable for example. Its your business logic, based on your requirements and SLAs. What kind of load? Not necessarily a specific load, but assuming an IOT cloud with thousands or more devices, I will expect the devices themselves to initiate the ping instead of the gateway, in order to take of some load from the gateway, but I guess this point is not clearcut. What is the purpose of the ping pong? To provide an accurate information if the device is there ( and delay statistics for example, ... ). Who is interested if the device is there? Cloud user. Who owns information if the device is online? Cloud. Cloud is the one who owns and maintains this information. Cloud should be responsible to ping the device to check if it is online. Device is not interested if cloud is there. You may have ping configuration per device, for some specific SLA use cases, but its cloud who has to accurately provide this information. Hi Ondrej, Just to explain how I see the "who is interested" matter... If you look at the "device is offline" as a fact / event, you are right, the cloud needs to detect it, report it, and then "someone else" provides the applicative handling of this event. However, there is a situation when a client establishes a TCP connection to the cloud, but the connection becomes "dead", so now it's the client's responsibility to detect this state, and re-establish the connectivity. [Ondrej] Yes, (client == device), device has to detect this state – that connection is down (I sent you link to the github with class which can help you to identify network adapter changes) and reconnect. Since security-wise clients usually initiate the connectivity, the cloud side can detect the issue, but not to perform the recovery. [Ondrej] Of course cloud can’t perform recovery. But that’s not the goal. But cloud knows when the device when down or when it’s not responding and in such a case, event that device is offline is raised. I think this need (on the client side) should be covered by the infrastructure, and not left for the developers of a particular application to figure out. How do you believe this client-side need should be addressed? I think this reconnection is up to the developer. For example in our case : let’s say you have multiple clouds – (IoTivity intefaces or in new implementation OCF CoAP Gateways). You were disconnected from the internal Cloud Interface A because it’s no more reachable. You’re no more in the same network. But you are in different network, where is Cloud interface B Max. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10015): https://lists.iotivity.org/g/iotivity-dev/message/10015 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] -=-=-=-=-=-=-=-=-=-=-=-
