waters at instapix.com
Fri Dec 20 21:11:53 UTC 2002
Is it true that this JEP ignores the case where the Initiator and Target
are both behind NAT?
It's unclear from the language whether, in the mediated case, the proxy
tries to connect to the target, or vice versa.
I feel that it is a mistake to leave out NAT<->NAT file transfer in this
Why not make the Initator and Targets all connect to the same proxy, and
then just take any data written by the initiator and write it down the
Here's a simple description of the proxy I'm using in my jabber client.
- you need a proxy P, which is reachable, and listening on a well known
port, say 80 for example...
- clients A and B both behind NAT and firewalls which allow outbound
connections to port 80.
- A connects to P, and registers a guid for their socket.
- P remembers this guid and holds onto the socket, possibly running
keepalive packets down it
- A tells B about that guid and P via the standard control channel,
in-band jabber in this case.
- B connects to P on the standard listener port.
- B writes the guid it got from A.
- P looks up the guid in a hashtable and finds A's socket.
- P creates and obhject that will take A's socket and the connected
socket from and write every packet it gets from A to B and vice versa.
- when either A or B closes, P gc's the object and closes the other
What scenario am I not covering with this style of proxy?
More information about the Standards