Why is the cloud heartbeat timeout set at 10 seconds, as opposed to, say, 1 minute or even 10 minutes?
It seems like a lot of issues with blocking code in the user loop() come down to the heartbeat timeout being so short. Is there a hard limit somewhere in the chain that necessitates the short timeout?
I think it’s probably 10 seconds because if it was 1 minute or 10 minutes, it would take that long to figure out there’s a problem before it tries to reconnect. That’s way too long to be down, imo.
That’s a good question. The CC3000 has a hard timeout at 60 seconds for open sockets, so we try to make sure something is being sent fairly frequently to make sure it’s open and reactive. Due to the nature of wifi and network programming on the cc3000, it’s hard to know if the socket is still open without actually trying to send something across.
Mohit is working on a very interesting modification to the firmware that will let these pings happen in the ‘background’ on the core so that blocking user code will no longer have the potential to knock the core offline.
Thanks!
David
It depends on the application though: the other side of that coin is that 10 seconds can be way too short to get much done in a single-threaded world.
I totally agree with that. That’s why I think Mohit’s solution to break the timeout ping away from the main loop is the best solution. Then you get the best of both worlds.
Yes, it sounds like a good solution.