Re: How to add new "protocols" ?

> From Tue Feb 18 23:09:27 1997
> > > > > 	1) try  alternate protocol, and use it if it works. Cache result
> > > > Increases the connection latency. Bad in general. Besides, 
> > > 
> > > Adds an extra RTT to first connection to host
> > 
> > Only if "fails" is by NACK. Otherwise, it adds
> > a timeout, which is usually in the 2-3*RTT range, _at best_.
> It should normally fail by NACK (with the equivalent of ICMP port
> unreachable), so that's not much of an issue. Since the result of
> the probe is cached, this is not more costly than a DNS lookup.
> Besides, you can probe in parallel all (are they 2, 3, 4 ? not
> certainly a dozen) the known protocols and continue the transaction
> using the preferred one among those available.

ICMP port unreachable is a "MAY", not a "MUST".

It also can increase the load on the server, especially
when you probe in parallel.

There is only one known protocol for which any of this
works, as pointed out earlier - TCP. 

Using non IP reliable full-duplex connection transports requires
redoing the rest of the URL anyway (to change the interpretation of the
host address and port, which is IPv4-specific), so using a new protocol
ID (http-tp4:) is necessary anyway.

Supporting HTTP over non full-duplex, connection-oriented protocols
requires other modificiations - i.e., serial numbers to associate
responses with requests, at least.

What is the advantage to a transparent selection of transport
protocol, given these constraints??

Joe Touch -
ISI / Project Leader, ATOMIC-2, LSAM
USC / Research Assistant Prof.      

Received on Wednesday, 19 February 1997 09:49:46 UTC