🚀 go-pugleaf

markb@spock.dis.cccd.edu (Mark Bixby) writes:
: 
: I notice that innd supports a "mode reader" command to force the socket to
: be handed off to nnrpd.  Therefore, if I get CERFnet to initially speak the
: innd command set with me, I can innxmit just fine.  I could also use NNTP-mode
: trn if I could convince it to issue a "mode reader" command right after
: connecting to innd.
: 
: Has anybody out there solved this problem?  Am I overlooking anything obvious?
: Trn 2.2 shouldn't be too hard to patch to try a "mode reader" command after
: connection; I thought I'd ask first to save myself the trouble of re-inventing
: the wheel.

This was implemented in the 'tin' newsreader, and I'm preparing a patch for
the NNR newsreader for VM.  As INN propagates, I expect this to be a problem
more often... in fact, it'll be a problem for sites that both forward news
via NNTPXMIT/INNXMIT/NNTPLINK and retrieve news via nntpxfer/nntpget as
well, because the latter have to switch to MODE READER as well.

It looks pretty trivial.  We don't run TRN here, so I'll have to leave
the specifics for Wayne to deal with.

Here's a few tips I've found by reading the INN and reference implementation
source, and poking the news-server at one of my feed-sites:

(1) If you are talking to a reference-implementation nntpd, rather than
    INN, MODE READER will get a 500 unrecognized command response.  No
    biggie.

(2) If you're connected to innd and enter MODE READER, it will kick you
    to nnrpd, which will validate your host and respond with a numeric/text
    response code.

(3) If your host isn't a peer, you'll be kicked directly to nnrpd.  Nnrpd
    will accept the MODE READER command as well, although it's pretty-much
    a no-op.  You should get a response, just as in case 2 above.

(4) If your host isn't allowed read/post access you'll get a 502 in response
    to MODE READER, and nnrpd will drop the connection.

(5) If you are allowed to post, you'll get a 200 response.  If you're read-
    only, you'll get a 201 response.

(6) If the server is not accepting connections due to load, disk space, etc
    it appears you'll get a 400 response.  Send a QUIT and close the con-
    nection.
--
Doug Sewell, Tech Support, Computer Center, Youngstown State University
doug@cc.ysu.edu	   doug@ysub.bitnet	<internet>!cc.ysu.edu!doug

cat core | uuencode bunny.dropping | mail jp@tygra.michigan.com