WCF client and server

Question

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.

Answer 1

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:

1. Server Load
2. Communication Path
3. Security
4. Multiple Clients Altering UI / Same Data
5. 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.