Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner
Date: Thu, 27 Jun 1991 17:20:44 -0400
From: Jim.Thompson@Central.Sun.COM (Jim Thompson)
Message-ID: <9106272120.AA11237@neuromancer.Central.Sun.COM>
Original-To: lear@turbo.bio.net
Subject: Re: should batch/ibatch/image/et al apply to the article command?
Original-Cc: ietf-nntp@turbo.bio.net
Newsgroups: list.ietf-nntp
Distribution: list
Sender: list-admin@cs.toronto.edu
Approved: list.ietf-nntp@mail.cs.toronto.edu
Lines:       55


	From lear@turbo.bio.net Thu Jun 27 14:05:47 1991
	
	Ok.  Here are some comments about your method, Jim.
	
	1.  Setup cost would be higher - establishing an extra TCP connection. 
	This is OK, if the NNTP connection is supposed to linger for a long
	period of time.

Temporal diameter will be reduced.  This is good.  We already have 
an implimentation that can forward articles in less that 150ms.  Just
how much less, we have yet to determine.  This obviously depends on the
wire time for sending the article.   Someone has to do something with
all those T3 bits.  (Hmm, will all of the average USENET article fit
in the wire between, say, Boston and San Francisco?)  
	
	2.  One of the nice things about the existing model is that it could be
	implemented on any reliable medium.  Your method pretty much nails it
	down to TCP, and protocols that support multiplexing.

Not really, any protocol that can support two stream connections between
the same endpoint qualifies.  I think I can do the same thing over an OSI
stack, (though I don't want to.) :-)  X.25 could also support this technique.
	
	3.  Somewhere in there we'll have to exchange byte count information if
	the BINARY or IMAGE options are also enabled.  

Not really.  This is TCP specific, but you could have the serving end
'shutdown' its part of the article stream after it was done sending.
using, the far end sees EOF.  Much like ftp.

You can then send the articles batched in, say, 'rnews' format, to
make extraction easy.  This requires IMAGE, of course.  Even without
this, you can send the articles, separated by "\r\n.\r\n", one right after
the other.  
	
Given that you've already negotiated what compression technique you're
using, you're still set.  LZW (don't shoot me Len) handles EOF quite
well.  Note that sending the articles in 'rnews' format under compression
is likely an efficency win, but isn't required.  

	Now.  What does this buy for 9600 baud connections that normal
	IHAVE/SENDME doesn't?

Compression is more efficent for a longer (larger?) data stream.  If you
follow the current model of IHAVE/SENDME, then you can compress,
at most, the contents of one article.  Thus, the 9600 baud connections
will benefit because they'll have more bandwidth for other applications.
Also, a compressed batch will have less affect on the 9600 baud line,
since it should 'trickle' across, rather than being blasted.  News
transfers should appear to be background noise.

Article propigation time may decrease for any site using this technique.
	
Jim