Subject: RE: Termination for SENDDATA command

From: [email-masked]
Date: Fri, 14 May 1999 14:56:08 -0400

Gentlement,

I just want to point out that we are talking
about locating a "." character right after and
followed by CRLF. A proxy would not need to 
know more than that.

In my book, this doesn't qualifies as a 
difficult parsing problem !

Andre Courtemanche
CS&T

-----Original Message-----
From: John Stracke [mailto:[email-masked]]
Sent: Friday, May 14, 1999 2:40 PM
To: John C Klensin
Cc: [email-masked]
Subject: Re: Termination for SENDDATA command

> as long as what is being transmitted
> is basically textual material that has to be parsed anyway

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.

--
/=============================================================\
|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 Stracke <[email-masked]>
Date: Fri, 14 May 1999 19:12:00 +0000

> difficult parsing problem !

I say again, it's not a question of being difficult, it's a question of
being inefficient.  With a byte count, you can prepare a buffer, call
read(), and forget about it (or, if you're doing non-blocking I/O, get as
close to that as you can without blocking).  With a fairly minor OS
extension, you could even say, "the next N bytes that come in on socket 3
should be sent directly to socket 5; don't bother me with them", and then
the data would never have to cross from kernel space to user space and
back.  Admittedly, most of us don't get to do OS extensions for our
servers; this example is an extreme case of the sort of optimization that
can be done, *if* the protocol doesn't prevent it.

---

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

> can be done, *if* the protocol doesn't prevent it.

Sorry, John.

If you get to tamper with the operating system, it is 
equally easy to hypothesize getting out and tampering with 
whatever is reading that data stream --note that you are 
making a *lot* of implementation assumptions in talking 
about "read()" and "socket N"-- so that it absorbs and 
transparently transmits everything until it sees a 
delimiter sequence.  If one has to do dot-stuffing, that 
stream-reader needs, worst case, a four byte buffer (".", 
".", CR, LF); if not or one is a little clever with flags, 
even less.  

By contrast, the byte count model requires that it keep 
state and run a counter as well as just transferring 
characters into a buffer and out again.  Which one is 
cheaper will depend a lot on the hardware architecture, but
I suggest that it is almost impossible to argue that, 
across architectures, the counting model is inherently 
enough more efficient to recover, over a decade of using 
the application, the number of cycles that have been used 
up already in this discussion.

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 May 1999 07:01:11 -0700

>being inefficient.  With a byte count, you can prepare a buffer, call

If you want to argue for maximizing efficiency -- and, as John K. notes, 
this would be true only for some hardware, but not for others -- you need 
to move to some other protocol set than the Internet applications.  The 
text orientation of most of them is inherently "inefficient".

Of course that fact applies only in one, very localized sense of 
inefficiency, and ignores larger issues of development and interoperability 
ease among multiple implementors.  It even ignores the very real increase 
in complexity, for some implementations, when using byte-counts.

Counter-intuitive? Yes.  Irritating to a good computer-scientists's sense 
of aesthetic?  Sure.

That's the problem with experience in this inter-networking realm.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: John Stracke <[email-masked]>
Date: Wed, 19 May 1999 16:02:14 +0000

Dave Crocker wrote:

> inefficiency,

True.  This happens to be an aspect where I put in a lot of effort in a
previous job (maximizing throughput in a message router for a commercial
conferencing app); but that was a relatively heterogeneous set of systems
(several Unices, with Windows as an afterthought), and it wasn't text-based.