[standards-jig] JEP 65 - Bytestreams

Dave Smith dizzyd at jabber.org
Thu Dec 19 14:25:31 UTC 2002

Hash: SHA1

On Thursday, Dec 19, 2002, at 05:18 America/Denver, Jan Niehusmann 

> I agree that 65 looks much cleaner in that regard, but at a cost: The
> user may have to wait for a TCP timeout (in the order of 30s-1m) if the
> first connection attempt doesn't work. Do you have a solution for that
> problem?
> A delay of up to 10s may be acceptable, but 1m is not!

You know, this scenario of waiting will still happen with JEP 46. If 
both parties exchange IPs that are fully NAT'd, neither party will be 
able to connect and you get the dreaded "1m" delay. Having both parties 
attempt to connect to each other in no way solves the possibility of a 
long connect sequence.

The possibility for TCP to "hang" is always there -- protocol CAN NOT 
get around this.

  It is the responsibility of the application layer, not the protocol, 
to keep the user entertained and hide as much as possible any delays 
which may occur on a network the size of the Internet. The code in the 
application should be smart enough to do something along the lines of a 
non-blocking connect with a timer to avoid lengthy delays. There are 
well known techniques for dealing with this issue.

> If this problem could be solved in any other way, I'd say it's a 
> perfect
> reason to drop -46 (or modify it accordingly)
> But I fear that any solution would involve connecting in both 
> directions
> at the same time, which is exactly the behaviour you want to avoid.

As I noted, connecting in both directions simultaneously doesn't really 
solve the problem. This is an implementation problem, not protocol. 
HOWEVER, it is much more difficult to implement a correct solution when 
there are no defined states that the implementation must follow -- 
again, the strength of JEP 65.


Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list