> On 17 Nov 2015, at 18:13, Jason Proctor <jason@mono.hm> wrote: > > greetings all > > IMHO, the assumption that the device still has the same IP address as it had the last time it and the cloud server communicated is problematic. > > in my mind, for various reasons, there will likely be a proxy server on the same network as the device, whose job it is to proxy stuff on behalf of an entity requesting access (it might also do some auth, etc). > > so the device communicates its abstracted address (eg HeartMonitor._wot._tcp.local for mDNS) to the cloud server, facilitating an address-neutral discovery on the way back. the proxy could also set up port forwarding etc for the duration of the connection. > > On Tue, Nov 17, 2015 at 3:39 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com <mailto:Claes1.Nilsson@sonymobile.com>> wrote: > Hi Jaime, > > The slides are here: https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/att-0104/Issues_with_bi-directional_communication_for_CoAP_and_other_IoT_related_protocols.pdf <https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/att-0104/Issues_with_bi-directional_communication_for_CoAP_and_other_IoT_related_protocols.pdf> > This will depend upon the context. In some cases, having a local powered gateway/hub that sits between the cloud and the IoT device is the way to go. This makes it easier to deal with sleepy devices, strong security, and to preprocess/multiplex sensor data to reduce the load on the cloud server. In other cases, the IoT device will connect directly to the cloud. Maintaining a “connection” through a NAT Firewall has its costs, so some such devices will be directly connected. A hybrid approach has the firewall in the cloud. With growing interest in low power wide area networks for sensors, that could be an increasingly popular choice. — Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
Received on Tuesday, 17 November 2015 18:28:13 UTC