ietf-nntp Pipelining/streaming

Clive D.W. Feather clive at demon.net
Tue Nov 14 01:50:48 PST 2000


Stan O. Barber said:
> 2. Section 7 -- Streaming .... There was proposed text on this that I didn't
> include in 11. My concern here is including this in the base specification
> rather than putting it in an extension. I think it makes a great extension, but
> I remain concerned about having in the base.

I assume we're talking about the same thing - the ability of the client to
send one command before receiving the reply to the previous one.

The first thing I note is that this is something that is built in TCP. To
break it, you actually have to do something special, like flush buffers or
pass control to another process. I know of a number of clients that issue a
batch of ARTICLE commands so that there's always data in the pipeline, and
I don't know of any servers that have a problem with it.

If we fail to specify this, then either:
(1) the situation is left ambigous, which I think is a bad thing, or
(2) pipelining is implicitly forbidden, in which case every news client I
    know of is not conforming. This is an even worse thing.
I really think it meets both the letter and spirit of what we're trying to
do.

Here's the wording I proposed before. It would go in section 4, just before
the paragraph beginning "The character set".

! 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.)

> Yep. I remain concerned about how to list which commands are
> "stream-able" and  which are not and how that list gets amended.

This is a legitimate concern. My own view would be that we come up with a
set of exceptions now, and leave it at that. Breaking pipelining requires
an effort, and anyone who needs a command to break it should be able to
explain why to our satisfaction. I've already listed those cases that
people mentioned.

If this is really unacceptable (and, if so, I'd like to hear why), then I'd
like us to at least have a list of commands for which pipelining *is*
acceptable. At the very least this should include all the commands in 9.1,
9.2, and 11.

-- 
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 



More information about the ietf-nntp mailing list