Subject: RE: **YOU'RE INPUT NEEDED** Termination for SENDDATA command

From: "lisal" <[email-masked]>
Date: Thu, 20 May 1999 07:28:11 -0700

This is late for me to speak up, I know, but I mentioned this debate to
some of our implementors, and being server guys, they are unhappy with
the performance effect this practice has on servers.  

Sometimes it makes sense to put the burden (in this case, of calculating
the length of the body) on the client; sometimes on the server.  In
cases where putting the burden on the client would allow the server to
process requests faster for all clients, and perhaps support more
clients, I think there's a good case for putting the burden on the
client.  It's not too hard for the client to figure out the length of
the body before sending it.

So before input is shut down on this topic, that's my 2 cents.

Lisa

> -----Original Message-----
> From: John Stracke [mailto:[email-masked]]
> Sent: Wednesday, May 19, 1999 9:02 AM
> To: [email-masked]
> Subject: Re: **YOU'RE INPUT NEEDED** Termination for SENDDATA command
> 
> 
> [email-masked] wrote:
> 
> > Looks like there appears to be some rough concensus on 
> <crlf>.<crlf>. Plus
> > it's an established practice.  I think we should put this 
> one to bed.
> 
> Agreed.  Concedo.
> 
> --
> /=============================================================\
> |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: Thu, 20 May 1999 11:01:27 -0400

Lisa,

 I don't want to cycle back through all the old arguments, but
this is a little burdensome, not at all burdensome, or an
advantage for the server depending on how the server is
implemented.  In the worst case, the overhead is small relative
to that of the TCP turnarounds of the underlying protocol.
Almost all of the efficiency/performance discussion has
ultimately been in terms of server-side performance (although,
in principle, we could go back and dissect each argument); it is
not just a client-load versus server-load tradeoff.

As I suggested less directly to John, if your "server guys"
believe it is worthwhile to try to squeeze the last bits of
performance out of this sort of thing, encourage them to
implement a low-level I/O routine that  reads characters off the
input port until it sees CRLF.CRLF, transferring each character
until it sees that and then setting whatever passes for an EOF
indicator in your environment.  It will be cheaper/faster than
character-counting in most of the environments I know (if I
recall from the last time I did device drivers in that
environment, a *lot* cheaper on your company's preferred Intel
architecture) and will leverage not only calendaring but just
about every internet applications protocol other than FTP.  The
per-transaction savings won't be worth it but maybe, just maybe,
if that were multiplied by every server-side instance of running
an application program and by every server your company ships,
the implementation and support costs for anohter interface would
break even in five or ten years.

And it would, IMO, _still_ be a better strategy to concentrate
all of the energy this takes to discuss and that sort of
efficiency would take to implement on tuning the very dickens
out of the TCP/IP stack itself: one of the first rules I was
taught about system optimization is that it is important to
concentrate on the _system_.  Specifically, one should not spend
a lot of time on small optimizations of events that don't happen
very often; it is much better to invest the energy in the
low-level activities that are, comparatively, executed orders of
magnitude more often.  

      --john

--------------------

--On Thursday, 20 May, 1999, 07:28 -0700 lisal
<[email-masked]> wrote:

> This is late for me to speak up, I know, but I mentioned this
> debate to some of our implementors, and being server guys,
> they are unhappy with the performance effect this practice has
> on servers.  
> 
> Sometimes it makes sense to put the burden (in this case, of
> calculating the length of the body) on the client; sometimes
> on the server.  In cases where putting the burden on the
>...