NNTP_TCPCMU_M - a multi-threaded nntp server interface for CMU-TEK IP/TCP 6.5.

Some points to note:

1) It would appear (although I haven't checked) that when a detached process is
created, ie. a WKS process, SYS$SCRATCH is not defined. Consequently, the
routine sys_remote_send in NEWSDIST.C will fail and so will any attempt to
distribute NNTP POSTed beyond the server's database. I've modified NEWSDIST.C
so that all references to SYS$SCRATCH (one of them) have been changed to
NEWS_MANAGER. This is reasonable since file creation at these points is done
with SYSPRV enabled.

2) The server interface 'simulates' the 'declaration' of the process as a
network object (c.f. DECnet and PSI) by always maintaining a passive listen on
port 119. On successful completion of the passive listen, the channel is handed
to thread code and another passive listen is created. It is conceivable that
another call could be made during the short period when a listen ISN'T in
progress - this will cause the IP_ACP to fire-up another server process. I
haven't added any code to check for multiple occurances of such processes (such
as using locks, etc).

3) Passive listens are maintained when MAXTHREADS is achieved. Calls are
accepted so that an NNTP service failure message can be sent. The call is then
closed and the passive listen re-established. This behaviour could be changed
so that when MAXTHREADS is achieved, further passive listens are disabled,
enabling the IP_ACP to fire-off more server processes.

4) Idle timeouts are used (IO$_CREATE parameter) to clear forgotten
connections. The only problem with this is that an idle connection is closed
without being able to send an NNTP service failure message. So far, I haven't
encountered any problems with this - rtass and rrn (the clients mostly used at
our site) re-establish contact without problems. Also, clients are often just
as rude, rather than sending a QUIT, they often tend to just abort the
connection.

5) When the number of active threads falls back down to zero, the server
terminates immediately rather than loitering for further potential connections.
I find this behaviour acceptable, others may not.

6) The server interface buffers an entire transaction for each active thread
because of the presumed limitations of mixing calls to malloc and free in AST
context (ie, I couldn't get it to work). Consequently, the stream of data
following a POST command will be buffered on the heap until "." is received and
only then will the next_function for that thread be called. Similarly, commands
such as LIST will have their outputs buffered on the heap until their function
completes. Just make sure that the process has enough PGFLQUOTA.

7) This code is free of debug and trace facilities. To debug this I tend to
rely entirely upon VAX DEBUG and VMXED. The code works well as far as I can
tell, errors are handled by abandoning the threads - no in-depth analysis of
exception codes is performed and no recovery is attempted within the confines
of the current thread.

8) The server code is compiled and linked as for the single-threaded version
(NNTP_TCPCMU.C).

9) This is the line we have in our INTERNET.CONFIG for the multi-threaded
server. It appears to suffice:

WKS:119:NEWSRV:TCP$NEWSRV:NETWRK:NETMBX,TMPMBX,PHY_IO,SYSPRV,SYSLCK:\
BYTLM=65535,BIOLM=32767,DIOLM=32767,ASTLM=200,ENQLM=100:\
SYS$NULL:SYS$NULL:SYS$NULL:4:5

where TCP$NEWSRV is defined as NEWS_IMAGE:NNTP_TCPCMU_M.EXE
and   SYS$NULL is defined as NLA0:
Note that SYSLCK privilege is needed due to rather strange behaviour on the
part of one of our mail protocol handlers - you probably won't need this.

I'd be very grateful if users of this code would send any fixes, improvements,
etc. to me as well as to the net or wherever.

Keith
--
Keith Halewood           Janet: keith@uk.ac.liv.cs.and
Dept. Computer Science,  Internet: keith@and.cs.liv.ac.uk
Liverpool University.
"If they're the only survivors of a nuclear holocaust then they can't be in
very good shape." - Beverly Crusher, ST:TNG