[standards-jig] A Proposal to the DTCP/JOBS/PASS madness

Dave Smith dizzyd at jabber.org
Fri Dec 13 23:16:16 UTC 2002

Hash: SHA1

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.


Version: PGP 8.0 (Build 349) Beta


More information about the Standards mailing list