NAT , wcf, duplex comm… need some insight

Question

I am researching doing a two way communication app, not necessarily peer to peer. Looking at using wcf, I am curious as to the inner workings on all of this. A big concern for me is NAT / firewalling.

I need to have this work without portforwarding on the clients. I will port forward the server, thats fine. but the clients need to be able to connect to the server, and then communicate back and forth through this now open (NAT and Firewall) connection.

The duplex wcf examples I am stydying, all seem to use a client address announced to the server to use for callback. Presuming this is a local lan adress, that wont work for public connections. If its the public address, port forwarding will be needed?

Am I missing something? I want to make a connection, keep it open, and use it in a duplex fashion. Thereby, getting past NAT and firewall restrictions once the client "dials out".

Further more, I am not quite sure on precisely how NAT is implemented. If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?

My final implementation would be:

Remote client <-> server behind port forward <-> management app issuing commands to the server which relays them to the remote clients.

Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.

Thanks for any insight provided.

EDIT: [PING-PONG] Hello Word?

Answer 1

With duplex services you can have independent communication between a server and clients.

Something to keep in mind about duplex services:

The duplex model does not automatically detect when a service or client closes its channel. So if a service unexpectedly terminates, by default the service will not be notified, or if a client unexpectedly terminates, the service will not be notified. Clients and services can implement their own protocol to notify each other if they so choose.

As far as the NAT/firewall settings preventing your services from working is indeed a good concern to have. However, your situation seems to fall in line with a typical two-way communication setup between client and server. I wouldn't suspect you having trouble getting things to work with a little bit of trial and error.

If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?

To my knowledge this is basically how NAT works. As long as the public IP of your server is accessible on port 5555 to both inbound/outbound traffic, you should be fine. You should maybe research or ask a question about this on Server Fault .

Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.

I don't think you're barking up the wrong tree. It just depends on what you're trying to accomplish. WCF will do a lot of the heavy lifting for you and let you focus on the core of your application. However, if you're wanting to learn more about socket programming then rolling your own network API/library would be something to continue doing.