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.
Related
I have a client-server setup which communicates via .NET remoting. We noticed after doing a netstat output on our server that the server had hundreds of socket connections to just one client. Once we shut down the client, the sockets, of course, disappeared.
I have built a small .NET remoting test server and client to see how extra sockets could be created via remoting. So far, I have found that since remoting calls are synchronous, the only way I could bind multiple ports was to make several different remoting calls in a multithreaded environment.
Our production client is not multithreaded during its remoting calls so seemingly, it only makes one call to the server at a time. My question is, does anyone know of a way in which .NET remoting would leave sockets open like this with only one client? Any configuration settings that might lead to this scenario?
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 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 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
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.