Re: Protocol Benchmarking (with Accept examples - long)

"Jon P. Knight" <>
Date: Thu, 3 Feb 1994 09:04:37 +0000 (GMT)
From: "Jon P. Knight" <>
Subject: Re: Protocol Benchmarking (with Accept examples - long)
To: Lou Montulli <>
Cc: Alexsander Totic <>,,,,
In-reply-to: <>
Message-id: <Pine.3.05.9402030935.A27151-b100000@suna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1788
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.

Just IMHO.


Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* Its not how big your share is, its how much you share that's important. *