views:

16

answers:

1

Hello all,

A broad question.

We have a client application that currently talks to a web service to exchange data between two clients. The first client stores data on the service and other clients poll the service to collect it at some later time.

We are looking to change this infrastructure a little in that clients will Connect() to the service supplying the IP and Port that they will 'speak' on. When client A wishes to send data to client B it will look up client B's IP and port on the service and then send the data directly to that IP and port.

In the situation where several clients exist behind a common firewall (and NAT), my gut instinct is that I would need to configure port forwarding for each client so that inbound messages at the public IP (ie public side of firewall) can be routed to the appropriate client. As our application is designed to shield 'techy' details we'd like to avoid this it all possible. One caveat is that we are quite happy for the client to have to open a port on the firewall, but to avoid the extra step of setting up port forwarding.

Hope this makes sense, and please feel free to ask for any clarification.

-- Edit -- We are aware of UPnP but it is a non-starter for us due to the fact that it is either not available on some routers and the fact that some corporate environments don't allow it.

Thanks,

Simon

A: 

Most home routers provide a UPnP interface to allow applications to set up port forwarding without requiring the user to do anything. Depending on the router model, they may need to enable it on the router, usually a checkbox in some buried config screen.

John Franklin
Thanks .. yes UPnP is a possibility but as it is not supported on many corporate networks and is disabled or simply not available on some routers its not a viable solution for us. Thanks for the reply.
Simon Rigby
Corporate networks? You won't be able to override corporate network security policy and programmatically open ports on their routers and firewalls. At best you could advertise "internal network IP" (i.e., the host's real IP) and "NAT IP" (the IP as seen when they connect to servers on the Internet), then try to connect on both. If both clients are behind the same firewall, they'll be able to connect on the host IP (maybe). The other option is to have everyone connect out to a cloud server and relay through it.
John Franklin