Bypass router using server to initiate connection

I would like to create simple chat program in Java, which could work on p2p basis. Using public server to only initiate connection. But I am not even sure this is possible.

I succesfully implemented chat solution in Java that work if at-least one PC has forwarded the right ports. I also managed to use external server instead od having to have forwarded ports on client side.

So I though, would be even possible, to somehow use public server to initiate connection, and than send data just right between clients, taking load off the server?

I am not very familiar with how routers work, but I expect when you call public server from internal IP, router remembers that call and incoming response from that public IP than sends to your PC. So I thought, maybe if first client connected to the server, server than passed information to the second client, maybe than they could somehow communicat开发者_高级运维e directly? If the rule in router was established by the server?

I hope I explained it clearly. If not please excuse me. I don´t even know how exactly this could be done, I just want to know if there is something right on my concept, and I have to study harder with chance of getting it operational. Thanks.

I think TeleHash is a new project that can do things like this. I only found out it about recently so I don't know much about it.

I made this answer community wiki so others can update it to explain how TeleHash could be used for this.

It's a vast subject, search for hole punching (for TCP: http://en.wikipedia.org/wiki/TCP_hole_punching)

Edit: After the comments (and reading the linked pages), I should retreat my advice. I don't delete it, for the nice graphic, but changed the last part.

If I understand right, you have two clients both behind a NAT firewall, which allows outgoing connections, but does not forward ingoing connections if not specially configured to do such (since they have no idea for which of the local hosts it is destined).

In principle, a TCP connection during its whole time of existence always connects the same two IP addresses and port numbers at these addresses (e.g. we have four numbers which stay constant). In the NAT case, you in fact have two connections, but this is not visible from the client computer A (nor from server S):

Client A  -------(LAN)------ NAT B      ------ (Internet) -------- Server S
  IP A                   IP B1 | IP B2                               IP S
  Port a                       | Port b                              Port s

The TCP packets have [A:a / S:s] (or [S:s / A:a]) addresses on the LAN part and [B2:b / S:s] (or [S:s / B2:b]) addresses on the internet part. The connection is identified by this [IP:port / IP:port] quadruple, so if you try to change even one of the four numbers, this has to be a new connection (or the packet will be thrown away).

So, if you first are speaking with your server, you can't continue to speak to the other client on the same connection, unless the server is forwarding the content.

The same is in fact the case for UDP packets, with the difference that there are no connections, and the NAT has to be smart and guess which packet is an answer to which other packet, and as such forward it to the right direction.

As pointed out by the comments and other answers, here is the point where the NAT can be tricked: We first send a UDP packet to the other client, which will get thrown away by the NAT there. But then the other client sends an answer packet which is not a real answer to the outgoing packet (since this packet was never received due to the other clients NAT), but the IP addresses and port numbers match, it still will be let through. This can get more complicated if the NAT also translates the port numbers.

For TCP, it can work similar, if both the NATs not really hold an open connection but simply forward (changed) packets when there was a SYN sent before. It is even more complicated, since also the TCP sequence numbers have to match here.