What about a reliable, connectionless protocol, like ARDP? (Well, it's
not really any more or less connectionless than TCP, but there is no
connection establishment overhead in ARDP).
> HTTP generates two datagrams for each query (or at least X-mosaic does)
The fact that Mosaic's request are more than one datagram is a big,
fat, BUG. It sends:
GET <url> HTTP/1.0
User-Agent: Mosaic xxx...
Accept: text/html
Accept: text/plain
Accept: image/gif
... (ad nauseum) ...
Accept: */*
Note that the last Accept: */* obviates the need for all the others, since
cost/quality qualifiers aren't specified. Except for some form submission
requests, requests should nearly always fit in one datagram. Any client
that implements a "save to disk" feature should just send
Accept: */*
unless it supports a feature where the user can specify preferences of
one format over another. Any client that does _not_ implement a "save
to disk" feature (like lynx in -anonymous mode) should explicitly list
the supported content types.
> and recieves a large number of datagrams back in response. The typical
> transaction profile consists of many queries to a single host.
Yes, but those queries are not conducted over the same connection, nor
should they be, except in the case of inlined images. Short connections
is one of the major wins of gopher/HTTP typical usage over FTP typical usage.
No server resources are consumed while the client user browses.
> HTTP
> POST operations are not idempotent. The loss of data is not considered
> acceptable. Therefore HTTP is not well suited to a connectionless
> paradigm.
HTTP POST is certainly an exception. But to really meet the requirements
of POST, you need real distributed transactions, with two-phase-commit or
something like that.
Dan