rsalz@bbn.com (Rich Salz) (06/25/91)
>news server. As Rich Salz mentions in another message, NEWNEWS is also >a good way of raping the victim host and sending its performance to >hell, since it's fairly inefficient in the way it's implemented. With the proper set of indices, NEWNEWS becomes as cheap as just about any other command. Of course, not every single host will be able to afford building the proper set of indices. :-) Jim Thompson knows the "proper set." /r$
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (06/25/91)
From: Rich Salz <rsalz@bbn.com> Date: Tue, 25 Jun 91 11:28:35 EDT With the proper set of indices, NEWNEWS becomes as cheap as just about any other command. Yes, but in the implementation which probably over 90% of the NNTP sites run, NEWNEWS is done by opening the history file, reading it out line by line, and performing a ngmatch() on each one. When your history file is 12 meg, and 230k lines, this is nontrivial. This ragging on an implementation really doesn't matter when we're discussing protocols issues, except that we should make sure that it's possible for a NNTP/NNRP server to elect _not_ to honor certain commands, such as NEWNEWS or the SEARCH commands that some people are requesting. The news admin at a particular site may not wish to spend the computrons/disk space for the various indices. Or a particular implementation of one of these commands could be done badly, and a particular site admin may wish to disable a particular command and remain within spec. I suppose that could be done now by making the NEWNEWS command return a "502 access restriction or permission denied" response, but perhaps we should have a more specific error code to indicate that a server is not going to allow a particular searching command (possibly because it's a specific index is not available or because it would return too much information). - Ted
rsalz@bbn.com (Rich Salz) (06/25/91)
Yeah, I agree that something like 520 Not enough resources for that command is something that should be codified in the spec. It is also tough to keep the difference between the protocol and the implementation separate -- and not too separate. Again, I apologize if I crossed any lines or stepped on anyone's toes. /r$
Jim.Thompson@Central.Sun.COM (Jim Thompson) (06/25/91)
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) From: Rich Salz <rsalz@bbn.com> Date: Tue, 25 Jun 91 11:28:35 EDT With the proper set of indices, NEWNEWS becomes as cheap as just about any other command. Yes, but in the implementation which probably over 90% of the NNTP sites run, NEWNEWS is done by opening the history file, reading it out line by line, and performing a ngmatch() on each one. When your history file is 12 meg, and 230k lines, this is nontrivial. This is likely due to the fact that the code that R$ mentions is not commonly available (yet), rather than reluctance by a large number of sites to innovate. If your newsreaders, or feeding arangements, need such indices, then you'll likely find the software and install it. Jim
lear@turbo.bio.net (Eliot) (06/26/91)
All, Since there appears to be no concensus on whether sucking or blowing is better, I suggest that we allow for both to continue, unless someone has a really compelling argument against sucking. AND, if we allow both to continue, then we should allow all the options to be applied to those transactions. Remember, the server can always say NO to an option negotiation. Eliot Lear [lear@turbo.bio.net]
sob@tmc.edu (Stan Barber) (06/26/91)
I have no objection to sucking per se. I just think NEWNEWS/ARTICLE is much more ineffective than some kind of GROUP/BATCH approach. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
lear@turbo.bio.net (Eliot) (06/26/91)
There is only one good argument against GROUP/BATCH that Dave Taylor would probably spout up with were he reading this discussion. He sees newsgroups as merely one of any number of search keys. In that light, it would not make sense to limit based *just* on the group. However, I think it would be good to flush out the READER specification before making any final decisions on this issue. See my next message for more info on the reader. Eliot Lear [lear@turbo.bio.net]