**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.