[standards-jig] JEP 65 - Bytestreams
dizzyd at jabber.org
Thu Dec 19 14:25:31 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
> reason to drop -46 (or modify it accordingly)
> But I fear that any solution would involve connecting in both
> 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.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta
-----END PGP SIGNATURE-----
More information about the Standards