Re: Protocol Benchmarking (with Accept examples - long)
atotic@ncsa.uiuc.edu (Alexsander Totic)
From: atotic@ncsa.uiuc.edu (Alexsander Totic)
Message-id: <9402022354.AA15398@void.ncsa.uiuc.edu>
Subject: Re: Protocol Benchmarking (with Accept examples - long)
To: altis@ibeam.jf.intel.com (Kevin Altis)
Date: Wed, 2 Feb 1994 17:54:19 -0600 (CST)
Cc: koblas@netcom.com, mcrae@ora.com, www-talk@www0.cern.ch
In-reply-to: <m0pRqP4-00041AC@ibeam.intel.com> from "Kevin Altis" at Feb 2, 94 02:52:54 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2407
> I definitely would like to see some way of doing multiple GETs with a
> single connection. However, the connection costs right now aren't that
> great except for the Accept. Perhaps current Accept usage should be
> rethought? Several issues to consider are:
I am not sure how great are the costs for Accept:. Since you need to send at
least one packet over the network, What is the difference between 50 bytes
and 1K worth of data sent?. Any networking people out there that can give
us better cost analysis?
Multiple accepts is a good idea, but I am not sure how feasible would it be
to implement. Right now, client could combine all the outstanding requests to
a one big one. I am not sure how well this will work in the future, with
possible proxy caching and URNs. Few other problems to think of: What about
order in which images are received and parsed? Some clients depend upon
some images arriving before the others. Whose responsibility would it be to
eliminate multiple requests for the same image?
> 3. Should the transaction be reworked so that the server says I've got this
> MIME type, then the client says YES or NO?
Not a bad idea. Maybe a two-stage process. The first request sends a list
of types supported internally by the client (similar to Lynx), and if the
choosen document is not determined to be one of these types, server requests
a confirmation from the client that a non-standard type can be handled. Client
could look up its master list, and if that fails ask the user if he really
wants to download an unusual data type.
> 4. The number of binary image formats and binary document formats is very
> large in the PC and Mac arena. Is it reasonable to assume in most cases
> that the document will simply be handed off to an external browser so that:
> Accept: application/*
> Accept: audio/*
> Accept: image/*
This defeats the purpose of type negotiation, which is to enable clients and
servers to cooperate in determining what type is sent to the client. So far,
we have not seen any use of this capability. I would love to see a server that
would serve PICTs to Mac clients, smaller GIFs to clients with a small screen,
automatically decompress the files if the client does not accept compressed
data, etc. I think that all this functionality can be accomplished with the
protocol as is. I am not sure how well would simplified versions work for these
cases.
Aleks