Re: Protocol Benchmarking (with Accept examples - long)
montulli@stat1.cc.ukans.edu (Lou Montulli)
Errors-To: secret@www0.cern.ch
Date: Thu, 3 Feb 1994 17:18:32 --100
Message-id: <9402031612.AA30075@stat1.cc.ukans.edu>
Errors-To: secret@www0.cern.ch
Reply-To: www-talk@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Protocol Benchmarking (with Accept examples - long)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2372
>
> On Wed, 2 Feb 1994, Lou Montulli wrote:
> >
> > If the host sent back the type immediately after the client sends
> > the get, the client could check it's list of accepts to see if
> > it's an acceptable type, for instance "image/jpeg".
> > If the type is acceptable, the client responds, "OK
> > send me the data", otherwise the client says "I don't understand
> > image/jpeg" but I do understand "image/gif and image/x-xbm".
> > If the server can deliver those types then he sends the data,
> > if not then the server may attempt a different sub-group, for
> > instance "application/x-mac-draw". In each case the client
> > would only send the accept header of the specified sub-group,
> > thereby saving the broadcast of a very large group of accepts.
> >
>
> Correct me if I'm wrong but currently we send Accepts in a single outward
> call and get some form of result (either the document or an error)
> returned from the server. With your scheme we send a request, receive a
> list of possible types, send back a request for types the client can
> handle and then get the reponse from the server. Therefore we've gone
> from one round trip delay to two. Thus to save transmitting a few bytes
> we take an increased latency hit. Right? When some of the network links
> have RTDs in the thousands of ms from where I'm sitting and yet we have a
> nice fat pipe to the Internet, I think we'd rather waste a few bytes on
> small documents. Latency is Your Enemy(tm) in WAN based distributed systems.
>
True, but 99% of the time the client will simply accept the first
type given by the server. The negotiation will only take place
less than 1% of the time, and in the case of negotiation the server
will most likely have to make some on the fly conversion that will
probably be slower than the latency.
:lou
--
**************************************************************************
* T H E U N I V E R S I T Y O F K A N S A S *
* Lou MONTULLI @ Ukanaix.cc.ukans.edu *
* Kuhub.cc.ukans.edu ACS Computing Services *
* 913/864-0436 Ukanvax.bitnet Lawrence, KS 66044 *
* UNIX! Cool! I know that! Jurassic Park - The Movie *
**************************************************************************