Subject: Re: Termination for SENDDATA command

From: [email-masked]
Date: Wed, 12 May 1999 17:50:18 GMT

One of our folks passed this to me:

>1]  Terminate the data with CRLF "." CRLF, escaping "."'s at the
>    beginning of a line a la SMTP.
>[Snip]
>2]  Provide a byte count when issuing the command,
>    eg "SENDDATA 2345".
>[Snip]
>3]  Provide a termination string when issuing the command,
>    eg "SENDDATA :=="
>[Snip]
>4]  Send data across another connection, a la FTP.

Don't forget to consider the performance characteristics of server's with
size constraints. If a server is unwilling to receive data greater than
size X, then options 1 and 3 require the server to receive all the data
before it can complain. Options

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Thu, 13 May 1999 09:14:26 -0400

John, you will have to commit your self here.
If you think there is better than what is
suggested, please put a proposal to the
list with the factual reasons why it is better.

Andre Courtemanche
CS&T

-----Original Message-----
From: John Stracke [mailto:[email-masked]]
Sent: Wednesday, May 12, 1999 10:00 PM
To: Doug Royer
Cc: [email-masked]
Subject: Re: Termination for SENDDATA command

> > before it can complain. Options

SMTP and NNTP are 17 and 13 years old, respectively.  We've learned a few
things since then.  Let's go for "good" rather than "usable".

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 May 1999 16:46:26 -0400

On Fri, 14 May 1999 18:39:46 +0000 John Stracke 
<[email-masked]> wrote:

>...
> > As long as processing speeds are a lot greater than likely
> > line/transmission speeds,
> 
> This is not always the case--if it were, then nobody would ever have an
> overloaded Web server.

There are probably counterexamples to my "as long as..." 
assertion, but this isn't one.  I suggest that, if you go 
off and profile the typical overloaded web server, you will
almost always find one of three things:

  * It is running on totally inadequate hardware, in which 
case little issues like how long it takes to find a 
CRLF.CRLF sequence are the least of its problems.

  * The problems are either in disk I/O or in directory 
lookup/access time, not in page processing/ evaluation.

  * The box is performing some relatively complex set of 
back office functions and they, and not serving out web 
pages, are sucking up the available cycles and causing 
performance problems.

> This is the main point I disagree with.  In the current protocol, with
> no proxies, it is true; but, if we want to be able to have proxies
> eventually, we should watch out for design choices that will make them
> less efficient.  A proxy does not need to parse the message it's
> relaying.

Absolutely not.  But, if I were designing an optimal proxy, 
I'd encapsulate the things in the format I intended to send
out and associate them with header and indexing information
so I could find and ship them quickly.  I'd certainly do 
that at storage time, rather than retrieval time, on the 
theory that the typical document would be retrieved many 
times per time cached (else why run a cache with or without
proxy functions).  The structure of that information, which 
might well include counts if that helped in the particular 
host environment, is irrelevant to the on-the-wire protocol
(if I'm worth what they pay me, nothing that could be put
into a machine-independent wire protocol would be as good 
as what I could set up with knowledge of the behavior of my
local environment).

And, if I were trying to design a proxy that just passed 
things through without inspecting them and without caching 
them, I wouldn't parse things, at least as I normally 
define "parse" -- I'd just do read/copy/write operations on
the data streams, per the comments in my earlier note.

Bottom line:  If you want to do a little (as in "not very 
much") optimization on some platforms/architectures, then 
counts will probably give it to you, but it will probably 
be small enough to be washed out by other factors. If you 
want to do serious optimization, one strategy or the other 
may be better depending on hardware and algorithm 
decisions.  Whatever decision the WG makes about this 
should probably be made on some other basis than worrying 
about the probabilities associated with gaining or losing 
the few machine cycles that are at issue here, one way or 
the other.
 
   john