Resend: ARDP vs. TCP; prospero as proxy
Clifford Neuman <bcn@ISI.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 25 Apr 1994 02:32:31 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199404250021.AA26859@darkstar.isi.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: bcn@ISI.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Clifford Neuman <bcn@ISI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Resend: ARDP vs. TCP; prospero as proxy
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Our apologize for taking so long to get back to you. We should have
responded to your ordinal message, but it got misplaced on our action list.
I'm interested in the possibility of using a Prospero in the role
that the HTTP proxy server is currently being used.
By proxy server, I assume you mean a server that accepts queries from
local clients, accesses the requested service on behalf of the client,
caches the result, and returns it to the client.
Prospero can fill this role for some kinds of data. In particular,
Prospero is currently best suited for storing directory information
(including Gopher menus), but it does not provide the data in the
documents themselves (actually, it can through the CONTENTS attribute,
but not as efficiently as it does directory information). We are
working on extensions in the form of a Prospero Data Access Protocol
(PDAP) that will provide better support for document retrieval itself,
and I'd be happy to discuss these with you further.
We are currently working on adding Prospero support to Mosaic, and
together with the data acess extensions I just mentioned, I think
Prospero could provide exactly what you want.
First, I'm interested in a comparison between ARDP and TCP. I gather
that transmission via ARDP uses less overhead than TCP. Are the
transactions supported by ARDP limited in some way that allows
optimization over TCP? Is ARDP "less reliable" in some way?
The goal of the Asynchronous Reliable Delivery Protocol (ARDP) is to
optimize the common case which is a one packet request, followed b a
one packet response. However, ARDP does support multi-packet
responses quite efficiently when needed, and it does handle retries if
packets are lost. What it is not suited to is a back and forth
interaction, where the client sends more data, after the first data
has been returned by the server. As to efficiency, because Prospero
is layered over ARDP, the overhead for connection establishment (in
terms of round trip messages) that is present with TCP is avoided.
Further, our server accepts requests and processes them in the same
address space, instead of forking a subprocess. Our server is also
multi-threaded, and if the load is such that all threads are in use,
requests are queued and are handled in the order received (or as
defined by user specified priorities and server heuristics).
Could someone describe in more detail the number of IP round trips
in the gopher-over-tcp vs. prospero-over-ardp?
For Prospero over ARDP
C: sends query to server on host:udpport
S: if server knows it will take a while, it sends ack, or it
S: sends response
The ack is piggybacked on the response if the server expects to
respond quickly. If the response requires more than one packet,
multiple packets are sent. Flow control only kicks in if the response
is greater than a server or client specified window size.
Finally... would it make sense for the prospero server to perform the
services of a gopher server directly? In other words, rather than:
C: look up "/xyz" link in #/INET/EDU/ISI/xyz
PS: send back link: HSONAME="1/xyz", ACCESS-TYPE="GOPHER '' '' ''"
C: connect to gopher server @isi.edu, send HSONAME "1/xyz"
GS: send back "/xyz" file contents
it might be nice to just do:
C: get "/xyz" from #INET/EDU/ISI/xyz
PS: send link info plus contents of xyz file
This can be done in two ways. At present, the contents could be sent
back as the contents attribute of a link. However, for sending
potentially large files, we are working on PDAP (mentioned above),
which could provide better flow control.
And/or, the client could, in the "get" request, include information
about what domains it can reach and what access methods it supports.
If the prospero server can access the file but the client can't, the
prospero server would do the gateway thing. Else if the client can
access the file, the prospero server just passes the link info along
for the client to resolve. Else you're out of luck.
This sort of caching and gateway functionality is supported by PDAP.
~ Cliff