Once the connection with that server is established it could connect both clients with each other without the intermediate server in the middle.
Lets take the router out the equation for a moment so I can understand the frame on top of which we are building. Both clients have connected with the server using http then the server sends the current ip addresses of those clients to each other ee client1's ip to client2 and client2's ip to client1. Now either client1 or client2 or both should open a port and wait for connections while at the same time trying to connect to the remote IP on the same port? (simplistic I know)
Yes. That's the most simplest form. But taking the router out of the equation is the most problematic 
But that depends on the setup of the routers. Some routers are set so strict even that wouldn't work and in that case all traffic needs to go over that server.
I'm not clear as to what you mean by "that" does the server do anything more than exchange ip addresses and other info (eg some public keys for cryptography), something to fool the routers to think that the connection was requested from the client and allow it?
Yes, if you include the routers again in the equation... the server could be used to puncture the whole into the router. Most routers are setup to allow traffic from ALL outside IP's once a internal client has established a connection with an outside machine. This is the simplest method of punching.
The inside client makes a connection with a server and an outside client can piggy back on that same port back to the inside client.
so something along the lines of
client1 open connection on port 4096 on server1. server1 acknowledged connection accepted. server1 inform client2 that port 4096 is open, client2 open connection on port 4096 on client1.
?
But other routers are setup more strict and only allow traffic from that same IP to where an inside client has connected.
Well I haven't see any router that ignores outside connection requests, to accept any connection from any one even the server that has already been connected by the client pc in the lan if the http server trys to open a port back on the client that made a data request to it then the client should never receive it the router should stop it.
If the outside client is behind a less strict server then the inside client can again connect directly to the outside client. But when both are behind a more strict router you have a problem. Neither client can get a direct connection with each other. The router2 doesn't allow client1 to connect to client2 and router1 doesn't allow client2 to connect to client1. And no method of whole punching can help there at which point the server need to be mediator.
so far that is my experience with a small exception UPNP. If the router supports UPNP and it is enabled then the client application should be able to add an exception on the router to forward the connection to a port to the client machine on the network. But yeah that is mostly a home router setup not a corporate one.
(But I seem to remember that there are several puncture techniques so maybe more than one should be used if the other fails)
any technique is good to know so if you have any reference or even a title, short description or name of a technique so I can google it would be grate. thanks for your time so far.
(You can see this with LogMeIn and Teamviewer. Sometimes a direct connection between two clients can't be established and then traffic will flow over their servers instead of direct from point to point.)
In the end, it doesn't matter which port the chat application uses. If the communication is done correctly it shouldn't be a problem to use http-port for it.
It should, I know routers that block all packets except http ee no nntp. smtp, pop3, imap etc so when I say over http I mean not only port 80 but http communication (get, set, put etc) this is to make sure that the more strict routers that allow only http packets to pass and block all others are letting us communicate.
Yeah. That's really strict. Almost as strict as just using a http-proxy. Those are the hardest. If you do have a server (mediating) you might just want to use http-traffic for the complete chat. I'm not sure if you can use the whole punching technique with these kind of firewalls. They (should) normally check if the endpoint stays the same. So in that case you would need to keep using the http-server for the entire chat. (And in case of a proxy this technique is not possible at all and you'll always need the server to channel traffic)
As for the format... You could just use a TCP-component and send (dummy) http-headers over port 80 followed by a binary package. I think you can fool the firewalls which just checks for HTTP-traffic.
Isn't that how the images are transfered from http to client? Why would I need a dummy header if I can simple use the binary data transfer?
So far I haven't seen a router that only allows html but I've heard stories about routers that cut off javascript from the incoming html documents.
Recent
