I want to create a communication between a windows service and a desktop application on Windows 7.
I read that named pipes are one way for communication between two processes. Can i use them for my purpose?
sure you can use named pipes, WCF many other IPC methods.
for named pipe example among stack overflow questions, see here as well for some backgound:
Inter process communication using Windows service
also check this one: GUI and windows service communication
As indicated above, there are lots of options available. Just be aware that if you go the TCP/IP route (e.g. WCF), the user will have to have a valid network connection (a loopback adapter will work) otherwise your client and service won't be able to communicate.
Go with WCF, it's a good solution to start.
Related
I have 2 windows form applications. 1st application interacts with database while the other application is aimed to communicate with the 1st application to interact with the database.
So how can I interact two applications with each other. Which tool should I use?
Here is a good example using WCF to communicate two processes:
http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication
Another option is ZeroMQ C# binding:
http://www.zeromq.org/bindings:clr
One option would be to use WCF named pipes (net.pipe) the other option would be Anonymous Pipes for Local Interprocess Communication
Excerpt:
Anonymous pipes offer less functionality than named pipes, but also
require less overhead. You can use anonymous pipes to make
interprocess communication on a local computer easier. You cannot use
anonymous pipes for communication over a network.
Use WCF with netnamedpipe binding as #I4V recommends. Other alternatives are use Pipes, Remoting, or fileshare.
What's the 'correct', or at least 'typical' way to communicate with a Windows service running locally?
I can see that it's pretty trivial to use WCF to open a HTTP or TCP endpoint, but both these are really network protocols.
What protocol should I choose to invoke methods and receive responses from a local windows service?
You can use:
Socket communications (TCP, HTTP, or other): even though you say they are network protocols the advantage is that you might already know them
Named pipes: this is a good option for communication between processes running in the same node: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx
shared memory: this is the fastest
Other third party, higher level, library like Thrift which uses sockets
I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!
I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service
You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking
We are building a window service that starts/stops other processes, and the communication between the UI and the service is with NetNamedPipe.
Every process have a host that can get shutdown call (still with NetNamedPipe in order to avoid port cross).
I have used it on my computer and when I moved it to the server it didn't work (NetNamedPipe is not for cross network - now I know).
Is there any way to do this right?
If this is going to run on the local network, I would suggest using a TCP endpoint on your WCF service to connect to instead of the Named Pipe endpoint.
For .Net - to - .Net communication, it's best to use NetTcp. You would use Http when mixing technologies (.Net to COM / Java, for instance), or when a firewall would otherwise block your communication.
So Http is what you use only if there are reasons not to use NetTcp.
I understand that trusted silverlight applications can communicate with each other over the LAN connection (peer to peer). Can they do this without an internet connection once installed out of browser? Do they need to first download some sort of Access Policy?
If not, is there some alternative way of doing this, perhaps with some kind of helper service on the computer?
Can they use similar techniques to talk to Local non-Silverlight devices, e.g. could a trusted silverlight application talk to an iPhone app over a local area network?
System.Net.Sockets.UdpAnySourceMulticastClient
Does allow you to connect between Multiple Silverlight applications on the same LAN. It does not require any internet connection after the application is installed out of browser.
I'm not clear if this could be used for communication with non-Silverlight applications althouh I believe it probably could since UDP Multicast is a standard protocol.
In situations where the network infrastructure is older it may not support UDP Multicast addresses. In this case, the best solution would be to install a separate local server on one of the client machines, to which all other silverlight applications could connect (once the user had typed in the IP address).
I'm not sure where you got your information from but as far as I'm aware there is no builtin way for Silverlight applications to connect to each other peer-to-peer. However it is possible to place a simple server application on the LAN through which Silverlight applications running on different nodes can communicate.
The plumbing needed to create peer-to-peer pipes is missing from Silverlight. It only has a means to connect to a specific TCP/IP port or to listen to Multicast UDP sources, it can't create a Listening port that waits for a connection nor generate UDP output.
You could go this by calling COM objects from Silverlight, however
Just because you can hammer in a nail
with a screw driver, does not make the
screw driver the best tool for the
job.
Have a look at using WPF so you get the full .net framework.