Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!olivey!root
From: root@olivey.olivetti.com (The Superuser)
Newsgroups: news.software.nntp
Subject: Streaming NNTP
Message-ID: <42723@oliveb.olivetti.com>
Date: 8 Jun 89 05:37:28 GMT
Sender: news@oliveb.olivetti.com
Lines: 39

The current NNTP transmits news in lock-step between server and client.
While this results in several benefits its performance suffers on links
where there is a long turn around time (rtt).  The impact is greatest
where the server already has most of the articles and the Ihave/Gotit
exchange predominates.  The current handshaking would seem to preclude
any kind of buffering of multiple requests across the link.

I have been thinking about a negotiated option to the protocol that
would allow the client to send multiple Ihave requests to the server.
The primary need on the server end is for the "Gotit", "Enter" and
"Thanks" messages to include the relevant message ID.  The client would
require a new message to indicate that the contents particular message
ID will follow immediately and the server would trigger on that as the
beginning of the article and use the given ID in the ack.

This would allow decoupling the transmissions of the client and server.
While the server would still process a single request at a time the
client could buffer up several message ID/file name combinations and
send them to the server before looking for responses.  Requested IDs
could be sent and refused or acknowledged IDs could be removed from the
buffer and replaced by the next entry from the batch file.

The disadvantages that I see for this are a slightly greater overhead
due to including the message ID in more commands.  There is also a
slight increase in the window during which duplicates can be sent.
Sending multiple commands in the same packet could offset the increased
amount of data.

The advantage would be an increase in the transmission rate.  In the
extreem case of all articles being duplicates there should be a steady
stream of Ihaves with a stream of Gotits flowing back.

Does this "streaming" mode seem like a viable option for NNTP?

The alternative would be to send blocks of message IDs and have the
server request only those it wanted.  While more efficient this would
require additional storage in the server and a negotiation to decide how
many it could accept.  It would also be more complex with regard to
error recovery.