2

I need to allow multiple clients (winforms apps) to connect to a server over the internet (in a remote location), and initiate duplex comms, sending at times a heavy load of traffic.

At the moment we are using duplex comms over netTcpBinding with WCF, secured over the transport layer with our own certificates. Although this works, I am concerned about a number of things:

  • Its a pain to setup - we create a certificate for each client to identify it with the server, and need to register the certificates for each client on the client machine and server
  • Because we're using tcp over a certain port, we rely on that part being open on the client end so that it can initiate comms over tcp. Some client locations don't like this.
  • We need to be able to guarantee delivery ideally

As an alternative, I was wondering about using wsDualHttpBinding, with a single SSL certificate to secure it, and have each client send some sort of identifier to identify itself. Will this solve the problems of firewall issues, and will it be performant enough over http instead of tcp? From what I know WCF will create 2 channels instead of one if you use http (since http doens't support two-way comms) - so that sounds like it could cause some issues with performance..

My question is, is this solution better, or are there other solutions (such as NServiceBus) that could make this easier and solve these problems?

EDIT

I've since learned that wsDualHttpBinding is not an option for me because: This binding requires that the client has a public URI that provides a callback endpoint for the service. This will not be possible for me.

Matt Roberts
  • 26,371
  • 31
  • 103
  • 180
  • Have you continued your project in netTcpBinding service or changing it to another WCF solution? I have a desktop app in client machines and a service in server which should be binded to each others via internet. – Hamid Dec 22 '15 at 04:52

1 Answers1

6

Let me address each concern separately:

  1. Why not use TransportWithMessageCredential and use usernames and passwords - that means you only need to manage usernames and passwords at the client and your client certificate issue goes away

  2. With NetTcpBinding the server needs to open the port for inbound traffic - the client only needs to allow clients to connect to that port, they don't need to allow an inbound connection on your specific port. Do they have an issue with allowing outbound connections to your custom port?

  3. NetTcpBinding uses Tcp which has guarantees of delivery assuming you don;t have a SOAP intermediary in the topology. Are you trying to guarantee delivery or processing?

WSDualHttpBinding will force your clients to open a port for inbound connections so will almost certainly not be acceptable. I wrote a blog article about duplex a while back which may help clarify the issues

You also might want to take a look at SignalR which is designed for this kind of scenario and although designed for web apps has a .NET client as well

Richard Blewett
  • 6,089
  • 1
  • 18
  • 23
  • Thanks a lot for this great response. I agree that the cert issue is clumsy, and using TransportWithMessageCredential does make sense. I didn't know that netTcpBinding guarantees delivery though, that's encouraging. – Matt Roberts Apr 19 '12 at 09:32
  • WRT using SignalR - I see that it fits the bill for 2-way comms, but I'm not sure how this works for .net client apps. For web apps, it uses websockets, falling back to long polling. But what does it use for a .net client app - is it just http? – Matt Roberts Apr 19 '12 at 09:36
  • By stating the obvious (i.e. use TransortWithMessageCredential) you really helped me simpify my code and remove the dependency on the certificates - thanks again! – Matt Roberts Apr 19 '12 at 13:23