tcp connection without connecting to a server

Is it possible to set up a connection between two computers without one acting as the host and accepting a socket connection from the client? I'm trying to get around having to forward ports so that it can be run on public wifi connections where port forwarding is not an option.

At first I thought this was impossible but then I started thinking about torrents. It seems that torrents are able to transfer data between peers without doing any kind of port forwarding. I assume this happens without everything going through some kind of central server.

Is this possible? Maybe would I need to setup a server to get the 2 clients together and then they could transfer data between one another without going through the server?

Any hints or advice is greatly appreciated. Thanks

> Is this possible? Maybe would I need to setup a server to get the 2 clients together and then they could transfer data between one another without going through the server?
Yes, that is why they're called "peer to peer" (p2p) connections, and not client-server connections.

Alright, any advice on where to start?

Try searching for "peer-to-peer programming" or "peer-to-peer in c" (or c++ or whatever).

EDIT: Found this. libjingle

Well from what I have read I don't think what I want to do is possible. I want a connection between 2 computers but without one listening then accepting the connection as a host so I just don't think its possible. If you are behind a router you have to forward ports to be able to do this.

My understanding of peer to peer is that some of the computers in the network have to listen on a port and accept connections in order for the network to work and I can't have that. Am I wrong? I don't want to use a library so if im wrong please point me in the right direction

Put it this way - you need one computer to send data to another. So one of those machines has to listen out for data coming in and, if there's something in the way like a router or firewall, it won't hear anything.

P2P works by connecting to already-known peers who are listening out. Where those machines are behind routers, they talk OUT to other people who aren't and thus join the network indirectly (so they ask the other side to pass on messages on their behalf). You can have networks that have only one listening peer but AT SOME POINT one of them had to be listening to establish all those connections.

A TCP connection, by design, has a source and destination. If the destination is not accepting unknown TCP connections from outside (the problem you describe), then you can't do anything to communicate with them without THEM trying to communicate with you. And that needs YOU to accept unknown TCP connections from outside.

There are various "NAT hole-punching" techniques but they all rely, at some point, on an intermediary server who accepts connections. It might be just the one (a "central" server), or there might be a proportion of users who have open connections and who will pass on data for others ("P2P") - especially if there's an incentive for them to open ports like "getting more connections to download from". But, at the end of the day, in a pure-NAT environment nothing TCP or UDP would work because nobody would be accepted unsolicited packets.

This is *WHY* port-forwarding exists. The only other workaround is to nominate an external machine without NAT that accepts TCP connections and acts as a proxy, maybe in a variety of clever ways to let NAT users use it as an intermediary. We usually call those "servers" and you don't tend to NAT servers and if you do you need to port-forward things to them so people can reach them. In P2P, it just so happens that the server is also a client that someone else is running to be "nice" to you.

Look at the TCP handshake process. It inherently relies on a new (SYN) connection being replied to by a server with an acknowledgement. Look at NAT - it's basic tenet is that it doesn't reply to packets connections that aren't part of its existing (outgoing) connections (usually because it has absolutely NO WAY to determine which local client they were intended for!). All a router does is put a NAT interface in the way so your whole local network can appear as, and share, a single external IP. The two concepts mean there's no way to have full communication between NAT'd clients without someone, somewhere accepting unsolicited (SYN) packets and acting on them. That means either no NAT at all, or a port-forward through a NAT.