[standards-jig] jep-0065 ([OOB] bytestreams)

Tom Waters waters at instapix.com
Fri Dec 20 22:41:47 UTC 2002


Whew!  I had thought so... pcurtis was telling me in jdev that it
wouldn't ever work for double-nat cases.

Is there an implementation (Started?) for such a proxy?  E.g. it's not
just a standard socks5 proxy, right?


-----Original Message-----
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org] On Behalf Of Matthew A. Miller
Sent: Friday, December 20, 2002 2:35 PM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] jep-0065 ([OOB] bytestreams)

In all* cases, the Target connects to the StreamHost.  This StreamHost
can be a proxy or the Initiator.  If this isn't clear enough in the
current draft, we'll make an effort to improve on that.

In any case, we certainly are trying (successfully, in my opinion) to
account for NAT/NAT connections.  It is one of the primary reasons for
this JEP's emergence.


-  LW

*  With "reverse connections" the Target becomes the Initiator for
purposes of establishing the connection, so this statement is still
true.

On Fri, 2002-12-20 at 13:11, Tom Waters wrote:
> 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
> JEP.
> 
> 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
> Target's socket?
> 
> 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
> socket.
> 
> What scenario am I not covering with this style of proxy?
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

_______________________________________________
Standards-JIG mailing list
Standards-JIG at jabber.org
http://mailman.jabber.org/listinfo/standards-jig




More information about the Standards mailing list