Server initiated communication to clients

Question

I am trying to build an internet service that executes commands on the connected computers. Commands are initiated through a web-based dashboard.

I currently have a REST API running with Laravel and the frontend dashboard application built out.

I am getting stuck on how to connect the clients to the cloud service. Clients will be running different OSs (Windows, Mac, Linux).

I have a .NET Core desktop client partially built, but am unsure how to connect it back to the server in a way that will allow the server to send commands. I'm hoping to get this communication close to realtime and scalable to 1000s of endpoints. It also needs to be secure transport.(possibly HTTPS)

Some technologies I have stumbled upon are gRPC, WCF, Websockets. Also found some other reverse tunnel technologies that probably won't work.

This will most likely be hosted on MS Azure when finished.

Any help would be great! Thanks!

EDIT: modified question to be more clear in what I researched and what I am considering.

Josh

Answer 1

Consider

• Websockets
• Signal R (recommended by MSFT for this type of communication, built on Websockets)
• HTML5 Server-sent Events C# client exists.
• Long polling. Works even when firewalls or old software block the others.

All work on all OS's mentioned. All support HTTPS over TLS.

Why won't these work?

It's unclear why you say Websockets won't work. If these tools won't work in your case you should probably explain why so you may get a more suitable answer. They are not perfect for every application but usually the apps for which they don't work have special requirements.

Long polling with async controllers on the server side works just about everywhere. It is certainly not as fashionable as the others, but very practical.

If you want to run the app on devices located anywhere on the internet these are things least likely to conflict with firewalls.

Long polling is a good fallback for any situation where more fashionable methods fail due to firewalls or network policies. It's just Http and involves zero requests from server to client. Just like a GET to a website.

Asynchronous Server Side For long polling from thousands of devices, it's generally worth making server side controllers asynchronous, since .Net supports that, to avoid parking thousands of threads waiting for a command.

Queue or Other Concurrent Blocking Structure With Websockets, a rest request can typically generate a message to a different device and user. It seemed for a while that every library or framework used a chat app as the example for websockets.

Long polling typically does not include this capability and usually depends on each GET request waiting on a blocking structure of sone sort, typically a queue that allows read requests to block.