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
Related
I want all web traffic (HTTP, HTTPS and DNS - Are there any others?) goes through a local application and goes to a server application and from there goes to internet. How can I do this?
I have wrote an Async TCP server and I know socket Async programming in C# using SocketAsyncEventArgs (I am not a master with just one project but I think I can understand some basics).
The only way to do this is to write a Windows network driver - you cannot do this from userland. This is how VPNs work.
There are userland tunnels you can develop that tunnel a single connection, but they require the user to configure their applications to use it first, so you cannot unilaterally redirect all network activity.
From your question, I'm guessing you're not too familiar with Winsock internals or writing kernel network drivers, so for now I'm going to say I think this is a take above your level of competence right now.
However if you'll settle for a bit of an impure approach, you can implement a SOCKS proxy easily enough, but this requires configuring browsers to use your proxy server - at least this way you'll tunnel HTTP and HTTPS, however I'm uncertain about whether or not browsers use SOCKS servers for DNS or if they use the OS-provided DNS functionality.
Like #Dai suggested, use a SOCKS proxy. It operates above the transport layer, therefore a SOCKS server can be configured to serve any application protocol operating on typical TCP/UDP.
This is exactly what TOR does to mask all traffic, not just HTTP.
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.
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.
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.