Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner
Date: Tue, 25 Jun 1991 15:04:11 -0400
From: Jim.Thompson@Central.Sun.COM (Jim Thompson)
Message-ID: <9106251904.AA05493@neuromancer.Central.Sun.COM>
Original-To: rsalz@bbn.com, ietf-nntp@turbo.bio.net, rickert@cs.niu.edu, sob@tmc.edu
Subject: Re: should batch/ibatch/image/et al apply to the article command?
Newsgroups: list.ietf-nntp
Distribution: list
Sender: list-admin@cs.toronto.edu
Approved: list.ietf-nntp@mail.cs.toronto.edu
Lines:       62


One of the things that I've suggested to R$ in the past few weeks
is a mode whereby two co-operating NNTP implimentations participate
in the following 


	machinea		machineb

	  res+n	----------------->  119   (1)

	    	<-----------------    (2)

	  res+o  ------------------>  res+p  (3)

	 	<------------------   (4)

Connections 1 and 2 are half-duplex 'haves' of a normal TCP stream, with
the NNTPport (119) on the 'b' side.

Connections 3 and 4 are the same, but with the NNTPport on the 'a' side.

Machine 'a' is sending news to 'b'.

During the setup phase, machine 'a' sends machine 'b' the equivalent of 
ftp's 'PORT' message, specifing a connection endpoint where it will accept
articles.  

'A' sends 'B' nothing but message-ids on (1).  B sends back the Message-ids
on (2) of the articles that it would like to see.  'A' sends the articles
on (3), and 'B' responds on (4) as to the success or failure of the
article or batch.

Note that the batch (possibly compressed) can trickle across the link as
its produced.  One needn't wait to have a fully-formed batch before its
sent.  In fact, if there are other users on your 9600 baud line, then they'll
quite likely be pissed because every few time quantum the equivalent of 
'rcp bigfile machineb:/tmp' will take place.  This will tromp on their
telnet session.  Machine 'A' must (obviously) keep track of which articles
are in the batch being sent across the wire until a 'got it all man, thanks'
message comes back from 'B', but since we're talking about message-ids here,
that shouldn't be a big deal, even on a 386 machine.

Note as well that Machine 'b' can keep track of the articles that it
has requested, and if it doesn't get one (or more), it is free to 
insert the message-ids in the 'gimme' (2) stream at some later point,
possibly on some other server.

Why all the complexity?

I don't want to see the proposed batching reduce what we've gained in
temporal diameter reduction.  News is now getting very fast.  With INN
I can forward articles from one spool to another in less than 200ms.
I really don't want to see a day when we go back to N hour delays just
because 10,000 sites have joined the Internet via 9600 baud V.32 connections,
and they're all batching news.  I've got nothing against 9600 baud
connectivity, in fact, I think I'm trying to help.

Note that this will require a "MODE" verb, as well as a "PORT" verb.

Fire at will, I'm sure someone will take issue with this.

Jim