[NNTP] Extension docs snapshots

Russ Allbery rra at stanford.edu
Thu Dec 2 10:16:48 PST 2004


Clive D W Feather <clive at demon.net> writes:
> Russ Allbery wrote:

>> but because it doesn't make any sense to do so.  The thing you're going
>> to want to do next is issue a CHECK or TAKETHIS command, and until MODE
>> STREAM returns, you don't know if you actually can or if you need to
>> use IHAVE instead.

> You don't know that the next thing is going to be a CHECK and, even if
> so, why does it matter? Suppose the pipeline depth is 3:

>     [C] MODE STREAM
>     [C] CHECK <msg.id.1 at example.com>
>     [C] CHECK <msg.id.2 at example.com>
>     [S] 501 What is MODE STREAM?
>     [S] 500 What is CHECK?
>     [S] 500 What is CHECK?

> Where's the problem?

Now try that again where the next command is TAKETHIS.

> Can we please go back to basic principles on this? The reason for
> pipelining restrictions is that some servers hand off certain commands
> to other processes and there is then an issue with which process gets
> which data from the socket. That justifies the restriction on MODE
> READER. The handshaking of things like IHAVE also mean that pipelining
> can't work.

The reason for the MODE STREAM command is that if you send TAKETHIS
without establishing that the server supports streaming first, really,
really bad things happen.  There is no requirement in the protocol to send
CHECK before TAKETHIS, and in fact servers are sometimes configured not to
do so in particular circumstances.

Really nasty interoperability problems happen if you pipeline MODE STREAM
and TAKETHIS together to a server that doesn't support streaming.  I think
we need to say something about that somewhere.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list