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        *
  **************************************************************************