I have this Windows Service that communicates with TCP/IP.
What I want to know is a method for a Windows Form Application to able to modify the setting of this service, such as remote host address and port to connect, timeout length, and log settings.
I have researched about NamedPipe, WCF Service, and IPC, but I can't decide what matches my scenario the best.
Will be nice to able to change the service settings by doing something like this from the client side.
[Service].SetTimeout(3000);
Any suggestions?
If you want that kind of programmatic control, then WCF is your best bet. With WCF, you get to define the API yourself, e.g., what methods to call, what messages to pass, etc. The WCF framework takes care of exchanging the data for you. And with the WCF config files, changing the back-end data exchange mechanism is trivial. For example, you could replace a NetNamedPipeBinding used for same-machine communication with a NetTcpBinding for cross-machine communication simply by modifying the config file(s). Full disclosure, though, if you haven't done WCF before, my experience was that the barrier to entry was pretty high. Of course, I took my lumps with Visual Studio 2008. It might be much easier in a more recent version. Here's an answer I gave a while back with some tutorials that helped me.
For me personally, I've replaced the early WCF implementation with a TCP-based version over localhost in the project I work on. The front-end application receives constant information from the Windows service when things are "running," and at the time of our decision, WCF streaming was not documented very well. We also saw evidence of problems, although that might simply be because we did it wrong. In any case, I'm very pleased with the solution we've come up with.
I can't speak to named pipes directly, but from what I've read, they're easy to use.
HTH.
Related
I need some help for a noob programmer. I have an application I built > assetcat.app
I am venturing into the depths of networking and looking to rebuild the app using a host / client system.
I have been building the foundation for this with WCF. But it has been a struggle with roadblocks at every breakthrough, I expected to get simple host/client environment with authentication setup no problems. But I have had issues with the network access on different IP's, certificate issues, and even just finding information on MSDN that shows example that doesn't use the app.config. As I need to do most stuff dynamically for portability.
I'm sure if I continue with WCF I will succeed but I'm starting to wonder if there is something more simple. It seams WCF is more suitable to some kind of in-house development were the company of the app also runs the server.
What I want to be able to achieve:
-User installs and manages their own instance of the server software.
-They create accounts witch anyone who downloads the client can point to.
So Bob wants to make a game and is working in a team, Bob installs the server app and sets up some user logins. Bobs team mates install the client app, set the pointer to the IP of his server app, and login. Everyone in his team enjoys access to content managed by the server app.
In this situation, should I continue with WCF? My concern is also around certificates, from what I have gathered I can just chare a development certificate for everyone to use. Each person who installs the server software is also going to have to create or buy a certificate? That seems like a whole lot of mucking about that nobody is gonna do.
WCF has been around for a long time and before what APIs generally look like today. WCF like SOAP/WSDL allowed for strongly typed contracts and in general (before JSON was a thing) shared messages via XML documents. Many enterprises still have WCF services for integration points.
Today, the modern trend is to have less strongly typed contracts, and share messages via JSON payloads. Rather than SOAP/WSDL endpoints you have basic HTTP listeners that can accept requests (usually POSTs) and parse the JSON to business objects. Many folks prefer to create stateless and Restful (or Rest APIs) as this aids with scalability and fault tolerance.
WCF would seem like the wrong way to go for game development. Restful APIs can still use transport and message encryption, but be a lot lighter weight than WCF which adds a lot of overhead and complications (contracts etc) that you probably dont need.
In terms of encryption, you could add SSL/HTTPS using a Let's Encrypt certificates. These are free to obtain.
I have a WCF service that will be hosted on a server and a WinForms desktop application.
I would like to implement two-way communication between them and was just after some advice on which is the best way to go about this?
I've done some looking about and the two methods I'm seeing mentioned a lot are either implementing a callback contractor using web sockets.
I'm just after some advice and guidance on which of these methods to take or if there is a better method.
I've used Callback Contract for school project and it served it's purpose nicely. If implemented well, it transfers any kind of data between the server and client. Callback is defined the same way as Contract. It's pretty simple and I advise you to look for some examples on Code Project , like this one Callback example , it's explained with minimum code. Also, in most books, Callback is used as an example for response from server. :)
You tag this question as winforms, so, probably, web sockets less relevant for it.
You can use callbacks (look for Duplex for mode details).
But if you have complex functionality on both sides, and firewalls on clients are not the issue - you can create 2 wcf "services" - one will run on client machine, another one - on server.
This will allow you to be even more flexible (for issue like server restarted, client restarted, ...)
I need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.
The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.
Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.
You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.
I'm relatively new into communication between applications, my goal is to have a Windows Service and somewhat a Managment Application where I can tell the service what to do, which methods to run (remote function calling). I stumbled upon "remoting", but a lot of people are telling this technique is deprecated and it's better to switch to something called WCF.
By this, I build my service according to this MSDN document:
http://msdn.microsoft.com/en-us/library/ms733069.aspx
I can install the service, run it, close it. But how do I interact with it? How does an "WCF client" application has to look like? It seems like WCF is something completely different to remoting, there are no server-client interfaces, no marshalled objects. I'm a litte bit confused, hope you can help.
You need have a Proxy/ChannelFactory for the client to interact with your WCF service.
On the client side you need a App.config/Web.config where you need to configure the endpoints the client has to lookfor for the service. You can do this programatically also.
Just go through the basics of WCF its easy than you think of it. :)
http://msdn.microsoft.com/en-us/library/ms731067.aspx
I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.
I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html