[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
dizzyd at jabber.org
Fri Dec 13 23:16:16 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
On Friday, Dec 13, 2002, at 13:17 America/Denver, Jan Niehusmann wrote:
> With Dave's protocol, first the target tries the TCP connection,
> waits for the timeout, then notifies the initiator of the unsuccessful
> attempt and offers a connection in the opposite direction. So even a
> successful connection may have to wait for a connection timeout first,
> which is unacceptable if it happens for each transfer.
Why is waiting unacceptable? It seems like an ordered process is
preferable to creating multiple connections and sorting out which one
is "real". At the very least, we get a comprehensible state chart and
possibility for robust implementation out of it.
> In order to work around that problem, clients would need to 'cache' the
> information that some connections are not possible and should not be
> tried, which means additional code complication. And how should a
> client notice transient connection problems?
You _could_ cache if you felt like it, but again, this seems like
making the solution more difficult than it needs to be. Using the error
codes and timeouts TCP provides seems preferable to blindly creating
connections and creating additional protocol to sort out which
connection is real. It's also debatable if it really is faster to
create multiple connections and sort it out.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta
-----END PGP SIGNATURE-----
More information about the Standards