Subject: Re: How to get NOOP out of pine?

From: Mark Crispin <[email-masked]>
Date: Tue, 7 Feb 1995 13:47:27 -0800

Some myths need to be dispelled here.

On 7 Feb 1995, Charles Cooley wrote:
> [NOOPs] also use network bandwidth, which is a precious resource at some
> sites.

A TCP/IP datagram containing a NOOP is 86 bytes.  86 bytes transmitted
once every several minutes is not a "precious resource" unless you're
using 300 baud modems. 

This is way down in the noise of bandwidth.

> Every ACTIVE connection eats away at system 
> resources, and server administrators take that fact into account when setting
> system parameters like timeout value.

This is a myth which the designers of TCP and TCP software (especially
Phil Karn of KA9Q fame) have tried for years to debunk.

By "active connection" you presumably mean "open connection", not
"connection actively transferring data" -- inactivity timers have no
effect upon the latter and thus it makes no sense to profer it as a
solution to the latter "eating away at system resources".  Open but
inactive TCP connections do not "eat away at system resources".  TCBs are
not finite resources. 

A lot more harm than good comes about by server administrators who play
around with server timeout values without understanding the underlying
mechanisms involved.  The purpose of server timeouts is to garbage collect
abandoned connections from PCs/Macs which were dropped without a reset,
since otherwise the PC will try to reuse the same port after rebooting and
find it can't get in.  They are otherwise to be avoided at all cost.

> You noted that NNTP is different
> than other protocols because it doesn't have a NOOP command.  You assumed that
> it was an omission through error, but perhaps it was a design decision. (I don't
> know which is true.)

Reinventing history is always fun, but I'd rather not do it here.  The 
NNTP protocol as specified in RFC-977 has a huge number of omissions.  In 
fact, RFC-977 doesn't even specify the protocol that is actually in use.

It is never wise to assume intent when error is a plausible explanation.

> Again, consider "reconnection" as an alternative to timeout suppression.

I fear that it will probably be about the time that hell freezes over that
I will finish the long list of tasks to make things work that currently
don't work (IMAP4 and IMSP loom high on this ever-growing list), and will
have the luxury to go back and redo things that do work. 

On the other hand, we provide source code.  If this is so important to 
you, why don't you write the code?