My question is, is there a good way to push an integer value to a running windows service without restarting it and without writing to disk or having it poll some database?
Here's my scenario and a few thoughts:
I need to pass data to a windows service in real time I DO NOT want there to be a delay. All I need to give it is in integer and it can do the rest. My predecessor had it set up to poll a database every 10 min but that is no longer an option. I need the response time to be less than a second. I suppose technically I could just reduce the poll time to 0.5 sec but I'm thinking that would be bad for the database server. I know you can pass data to a windows service when it starts but restarting this service isn't an option because of what it's doing.
I would love to use a web service and just call a web method to pass in the data but the tasks require elevated (admin) permissions and almost everything involves file system access so my understanding is that a web service isn't really the best option either.
I've thought of using a hybrid scenario where I run a web service and a windows service on the same machine but then I still have the problem of how to pass the integer from the web service to the windows service... I could technically use a file system watcher but I really don't want to create a file just to pass an integer. I thought maybe I could use localDb and have the web service just write the value there and have the windows service poll localDb every 0.5 sec, But I'm not sure how much that polling would affect overall performance of other things. I really want a way to push data to the windows service rather than having the service poll somewhere else.
The project I work on has a front-end UI that communicates with a Windows Service running on the same system. In the past, I used the Windows Communication Foundation (WCF), but found this to be heavy-weight for what I really needed. I am now using a TCP socket over the localhost address (127.0.0.1) to exchange data between the UI and the service.
Based on your description, the web service approach seems heavy-weight, kinda like the WCF approach we used to use. And, as you've noted, it has permissions issues. A simple application that pushes the integer to your service over a socket would be straightforward in my mind.
If WCF is of interest, here's a couple links that might help:
Creating a user interface for monitoring and interacting with a running windows service
GUI and windows service communication
Related
I have written some code that calls an executable and passes arguments to it via the cmd line.
For example it will call
my_process.exe -A my_argument
What I want to happen is that my program my_process will always be running looking for user input and instead of creating a new instance of the process I am wanting to write my data/arguments to the existing process.
I understand that how I am passing the parameters will change from the the initial process start (argc, argv) vs when using stdin.
I also know that I will have to change how I am calling the process but I am unsure of what I need to look into to get this done.
EDIT: so what I am trying to accomplish by doing all of this is below:
Website >> Web Service API >> Hardware API >> PLC
The website is on server A, the web Service and Hardware API is on Server B
OS is Windows 10 Pro 64bit
PLC is a programmable logic controller
The website will send a post to my webservice. The webservice will call the Hardware API which in turn will write or read data to the PLC.
This works when doing a single POST. But when doing multiple POSTS if the connection from the Hardware API to the PLC is still open it will fault.
The Connection between the Hardware API and the PLC is like a COM port not like a socket (which is misleading based on the programming manual).
So what I was trying to do was to keep my Web API the same but create another process that will take all the results from the Web API and put them in a FIFO and then pop them off to the Hardware API (which I will always have running and will have a persistent connection to the plc).
So really the Hardware API would always be running and be a single process that gets data passed to it. The Queue service would always be running and the Web API would pass the results over to it.
I have looked into the below:
https://www.boost.org/doc/libs/1_37_0/doc/html/interprocess.html
child/parent process/fork/file descriptors/dup/dup2
Any thoughts or advice is greatly appreciated.
I am trying to use an UWP app service to provide some non-UI processing service to other app including the host app. For responsiveness, I want to return the result progressively. Think about grep-ping a folder for files containing a certain string: It would be better to report the files as we found it instead of reporting everything at the end.
So my question is: Can this scenario be achieved with the current UWP technology? (I think it is probably possible via polling using the multiple app instances approach. I want to know if there's an easier method with app service.)
The AppServiceConnection is a bi-directional communication pipe, so you can use it to communicate progress updates from the service to the client. No need for polling. Just retain a reference to the AppServiceConnection instance in your service implementation once the client has connected and then call SendMessageAsync to send progress updates to client whenever you want.
Background:
I've a local application that process the user input for 3 second (approximately) and then return an answer (output) to the user.
(I don't want to go into details about my application in purpose of not complicate the question and keep it a pure architectural question)
My Goal:
I want to make my application a service in the cloud and expose API
(for the upcoming website and for clients that will connect the service without install the software locally)
Possible Solutions:
Deploy WCF on the cloud and use my application there, so clients can invoke the service and use my application on the cloud. (RPC style)
Use a Web-API that will insert the request into queue and then a worker role will dequeue requests and post the results to a DB, so the client will send one request for creating a request in the queue, and another request for getting the result (which the Web-API will get from the DB).
The Problems:
If I go with the WCF solution (#1) I cant handle great loads of requests, maybe 10-20 simultaneously.
If I go with the WebAPI-Queue-WorkerRole solution (#2) sometimes the client will need to request the results multiple times its can be a problem.
If I go with the WebAPI-Queue-WorkerRole solution (#2) the process isn't sync, the client will not get the result once the process of his request is done, he need to request the result.
Questions:
In the WebAPI-Queue-WorkerRole solution (#2), can I somehow alert the client once his request has processed and done ? so I can save the client multiple request (for the result).
Asking multiple times for the result isn't old stuff ? I remmemeber that 10 - 15 years ago its was accepted but now ? I know that VirusTotal API use this kind of design.
There is a better solution ? one that will handle great loads and will be sync or async (returning result to the client once it done) ?
Thank you.
If you're using Azure, why not simply fire up more servers and use load balancing to handle more load? In that way, as your load increases, you have more servers to handle the requests.
Microsoft recently made available the Azure Service Fabric, which gives you a lot of control over spinning up and shutting down these services.
I have a web site that exposes a web service to all my desktop clients.
Randomly, these clients will invoke the web service which in turn will add a message jpeg in byte array format to the MSMQ.
I have a service application that reads from this queue and performs an enhancement on this jpeg and saves it to the hard drive.
The number of clients uploading at anyone time is unpredictable.
I choose this method because I do not want to put any strain on IIS. The enhancements my service application performs is not much 'erg' but it exists nevertheless.
However, after realizing that my service application had stopped for sometime and required restarting I noticed the RAM leap up to clear the backlog. Whilst I have corrected this and the service is now coded to restart automatically on fail I surmised that a backlog could exists at busy times which again give a higher RAM usage.
Now, should I accept to do the processing all within my web service and then save to the hard drive or am I correct in using a MSMQ?
I am using C# and asp.net
I am building a web application, not hosted by the client but on the cloud somewhere, probably azure. It will need the ability to access some local devices such as a receipt printer or cash draw from where they run it. Via a browser this is obviously not possible.
I was thinking of creating a service that they can install locally on their PC that listens to a web service and when it gets a message can perform the tasks such as opening the cash draw.
Is this how people have done similar things in the past? Are there other methods? What technologies do you recommend as I plan on the local service being able to be run on either PC or Mac with minimum fuss. I was considering either Flex or Mono (the app was written in ASP.NET), any other suggestions?