-2

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

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.

  • This is great information! Thank you. I mean the reverse tunnel technologies probably won't work like ssh and http reverse tunnels. I was considering the other 3 I mentioned but wasn't sure how they scale. – josh13564 May 21 '18 at 0:50
  • So what I am thinking is using Signal R and creating the hub with asp.net core. What's nice about this is my dashboard app can initiate commands directly through the hub without hitting the php server/api. My only concern is syncing the client IDs from the hub to the dashboard app so the commands will go to the correct computer. Not sure if I need to implement this myself of if signal R has this build in somehow. – josh13564 May 21 '18 at 2:20
  • FWIW, I’m reasonably certain SignalR will gracefully degrade to long polling if the client doesn’t support Websockets. – RubberDuck May 21 '18 at 16:24
  • @RubberDuck If you use SignalR's client code, I think you're right it can degrade if it can't get a Websocket connection, but only from reading. I have not tried it. I work with Java, Javascript lately. Other libraries offer this feature too. – joshp May 21 '18 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.