Hacker News new | ask | show | jobs
by kdv 2931 days ago
You sound like you have some experience in this area so I'll ask. I'm working with fielded devices that typically sit on enterprise networks. We operate much like an IoT device, but without the hardware constraints. The current c2 system uses a traditional polling REST HTTP protocol and we're looking to migrate something more real-time (for config pushes) and lighter on the server. Currently looking at everything from HTTP/2 SSE, Websockets, MQTT over WS, or even HTTP using something like Google's Cloud IoT. As you can probably tell we'd like to keep the wire protocol enterprise-network friendly. Any advice?
1 comments

It really depends on your edge data model, but the enterprise network should always be considered hostile.

At my previous company we ran SSH servers on our gateways for server->client pushes and it ran into the fewest problems with enterprise firewalls. We also ran our own mesh wireless networks a lot using our own gear. I'm guessing that's probably not an option, but when there's no admin running around looking for unauthorized wireless signals it's quite efficient.

Now all of these require a local host machine (or several) behind the firewall that do the brunt of routing and orchestration for pushes. There's a good reason for it though: It's a lot easier to get several hardened systems authorized to cross the firewall than a bunch of IoT devices. And if you can't get that authorization, you can put a cellular connection in the box or boxes more cheaply than one in every deployed device.

Happy to chat more if you want specific advice about certain situations. I also spend a lot of time investing in and mentoring Boston-based IoT startups so I have seen a broad cross-section of situations that can happen. brendan@sentenai.com

We have the full support of the network admin staff, so punching out is not an issue, we just want to keep it as clean as possible. My guess is our control channel will likely end up being some combination of WSS/Redis (if it plays nice w/ mutual auth and load balancing) or a variation of our current polling HTTP/REST solution. Thanks for the offer, I might take you up on it ;)