Um, that won't go trough NATs, if both sides are NATed.. (if you do not have NATs, you are lucky and I envy you a lot. That wile creatures are destroying the Internet).
This is ultimately for public consumption (like yahoo), so we cannot ignore presence of NATs. The idea was to use following sequence:
1. client1 tries to connect to client2 2. if method1 fails, client2 tries to connect to client1 3. if method2 fails, use server based routing.
And, by the way, I would discourage you from using port 80, unless you intend to use http on that. 80 belongs to http and people expect web pages to be there, besides, you need (under some systems) administration rights to bind low ports. If you to that over TCP, choose either some random (or let the OS give you one) and negotiate it over XMPP, or choose something that is not used by something such widely used as http.
Point duly noted. I suggested 80 as many firewalls are flexible with port 80. This will result in more P2P connections than using any other port.
Yes I agree that there is lot of complexity with P2P chat. Since audio/video applications have to solve these problems anyway, I was hoping to get a free ride. I think those days have yet not arrived.
- Ravi
