C# – WebSocket Client as an always running service

asp.netciisnetwebsockets

The company with which we are integrating is a door security company that makes RFID cards and door scanners. You scan your card, the door opens and lets you in. They allow 3rd party integration via their websocket server. They post "Events" to their server. "Bob Foobar scanned his card at door reader #14 at 8:12am on 2/26/2018" all in json format. We need to constantly listen for all of those events and log them in our database.

We give our clients two options. We cloud host our service in a multi tenant SAAS environment. But we also allow customers to self-host if they want. If we only had the SAAS option, then this would be a simple solution. Just create a Windows Service that runs on our servers to subscribe to their websocket server. But, for our self-hosted customers, we are hoping to avoid asking them to install a Windows Service. We are looking for other ways to make this happen. But, we also don't want to ask them to open a browser window and keep it open.

I need to subscribe to a remote websocket, and I need to do it in such a way that it's always listening, even w/o user interaction. This isn't a chat type service that is user-centric. We need to always be listening for events as they appear on the remote server.

I've been reading up on System.Net.WebSockets, and I've seen lots of examples. I have built a proof-of-concept as a Windows Service, and it works.

But… is a Windows Service really the only way to always subscribe to the remote websocket server w/o user interaction? What other options do I have? And, is it possible to accomplish this strictly using IIS?

Best Answer

I think there are 3 or 4 kinds of process:

  • Applications started by a user
  • Applications started automatically when a user logs in
  • Services started when the O/S boots, before the user logs in
  • (Device drivers)

If you want your process to run:

  • Before a user logs in
  • and after a user logs in
  • and after a user logs out

... then it does need to be running as a ("system") service, instead of as a ("user") application.

Alternatives:

  • Run it as a plug-in of an existing service -- in that case, the architecture and administration (e.g. installation) of the plug-in, and its security context, depends on the service (e.g. IIS)
  • Run it as a user application, if you don't mind the user being able to kill it and you don't mind it starting and stopping when the user logs in or out
Related Topic