devicehive / devicehive-cpp Goto Github PK

The DNS resolution in the client is called asynchronously, but if the call does not return, the connection layer hangs and does not return control to the application layer or report failure.

Hi,
I have been working on device hive framework recently.since I am trying to extend the current functionality to full fledged IoT framework. Our sensor device will not be having OS and hence C code would be used while Gateway will be having OS and hence we are using C++ framework code.

1. I am expecting the communication of gateway with server using TCP-IP [ over wi-fi]/ GPRS. Does boost.asio component provides such communication component? If not, how can we integrate in the same in existing framework?
2. Current gateway project solution is only one sensor communication with gateway. But, We are trying to extend devicehive framework for multiple sensors connected with gateway and multiple gateways connected with server. Please throw some light on scalability of devicehive for IoT purposes.
   3, Our sensor device is having RF Rx/Tx which uses RS232 protocol for data communication. So, Eventually we have wireless communication between device and gateway. In such case, does boost.asio suffice the communication purpose on gateway? (I have not yet seen C code for sensor device)
3. I am just concerned about the memory foot print when framework is extended for multiple resources. Please let me know current foot print for a single device

Hey,
I'm wondering if this library is still being updated/patched? Looks like 2 years since the last push.

Thanks.

I've noticed a couple issues with connectivity on the device hive. In particular there are cases where the library fails to rebuild connection with the server after network interrupts.

• If the server goes down, I've noticed the device hive library(web socket mode, java server side) has an approximately 10% chance of not catching the network disruption and hanging in an 'zombie' state. I believe* this occurs if the disruption occurs when there is a packet transmission, and the application loop is never called again.

My current work around was to implement a watchdog timer of sorts using linux's timer_create, and exiting the application forcefully. We use a wrapper script around the application, so the app is restarted... but we cannot rely on state being stored in memory if the application can hang at any time.

*(not 100% sure on the underlying cause, but it looks like some time of blocking request)