So I’m really getting going with my project, finally, after months of not having time.
But I am reading and experiencing so much unreliability with regards the cloud services as a whole, and spark subscribe/publish specifically that I am wondering if I am going to spend an age building and programming and then end up with an unreliable system.
Would I be better off just connecting my Cores with wires?
Basically I have four Cores and want them to all communicate with each other (but passing on REALLY infrequent and simple messages). The thing is, when that infrequent and simple message gets sent, it NEEDS to be received and acted upon. A couple of “missed messages” would cause my staff to lose all confidence in the system I’m building for them. A delay of upto, say, five seconds is fine for the message to be received and acted upon.
So what do you reckon? Anecdotally or otherwise, what’s the craic?
Error checking is an essential part of the project.
You could start by setting up some kind of heartbeat check, so if connectivity is lost, the system knows about it and can take appropriate action, like telling you that a node is down. Sending messages into the void without some kind of confirmation that they have been received is also unacceptable if the messages are critical.
And take out the middle-man as much as possible, the more intervening services that you have, the more points of possible failure. So nodes should talk to each other directly, and websites accessed directly whenever possible, not with hooks or redirects. If the messages don’t have to leave your local LAN, there is no reason that they should hit the WAN.
Regardless of how you connect the devices (WiFi or wired), you still need to check that everything is working right, in case a cable gets disconnected or a node loses power,
To Awake’s point, aside from a regular heartbeat (because it’s not clear what one Photon will do if the other Photon doesn’t exist. If detecting photon is connected only to a motor, for example, what can it do? That being said, an LED that indicates error would be valuable), if your messages are critical, make sure THOSE have some sort of response / acknowledgement. That way you can ensure your message is sent reliably because you can resend and resend until you get a response back. If you number the message, then you can send it 50 times and the other end will know to ignore duplicates because they have the same number. You wouldn’t be at risk of duplicating events because a packet took a little longer to get there than you expected and you resent.
Also, abstract away – that way you can drop in whatever communication you deem fit now and in the future. If one’s not reliable, replace it! If one’s too slow, replace it!