ietf-nntp Pipelining

[Clive D.W. Feather]

Definition:

A pipelining server is one that will correctly handle the situation when
a client sends a command before the server has sent its response to the
previous command.

Discussion:

Pipelining is, in general, a good thing because it eliminates the turnround
time between commands. Many NNTP clients already assume that pipelining
works. For example, they will issue a bunch of ARTICLE commands before
looking for the response to the first one, then issue another ARTICLE every
time a response is received.

In most situations, a server written in the obvious manner will be fully
pipelining, since the TCP input buffer will hold the next command until
the server is ready for it. However, RFC 1854 indicates that there are two
major problems with SMTP servers:

(1) Some servers flush the TCP input buffer when an error occurs.

(2) When a server does an internal process handoff, the TCP input buffer
may be emptied as a side effect.

I suspect that both of these are much less of a problem with NNTP because
of the wide deployment of pipelining clients. So I suggest that pipelining
should not be an extension but rather defined as part of the core protocol
since it represents current practice.

When the topic was discussed before, nobody was able to list a server that
got this wrong.

Note: if we don't allow pipelining by default, we should be documenting
that fact and requiring clients to be changed to not use it. I can't see
that being popular.

Proposal:

In section 4, add the following two paragraphs just before the one about
the character set being UTF-8. I have made this change on my web site.

  Providing that the next command will not depend on the response
  from the previous one, an NNTP client MAY send a command before
  receiving the previous response (and may send multiple commands
  in this manner). The server MUST NOT flush or otherwise lose the
  contents of the transmission layer (e.g. TCP) buffer. However
  there are two exceptions: the client MUST NOT send any command
  until the initial greeting response has been completely received
  (including the terminating CRLF), and it MUST NOT send any command
  after MODE READER or LIST EXTENSIONS until the response to that
  command has been completely received.
 
  (Note: if the client uses blocking system calls to send commands,
  it MUST ensure that the amount of text sent does not cause a
  deadlock because it is not reading responses. The amount of text
  involved will depend on window sizes in the transmission layer,
  and is typically 4k for TCP.)

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646