N NNTP_TCPCMU_M - a multi-threaded nntp server interface for CMU-TEK IP/TCP 6.5.   Some points to note:  O 1) It would appear (although I haven't checked) that when a detached process is I created, ie. a WKS process, SYS$SCRATCH is not defined. Consequently, the J routine sys_remote_send in NEWSDIST.C will fail and so will any attempt toM distribute NNTP POSTed beyond the server's database. I've modified NEWSDIST.C H so that all references to SYS$SCRATCH (one of them) have been changed toL NEWS_MANAGER. This is reasonable since file creation at these points is done with SYSPRV enabled.  I 2) The server interface 'simulates' the 'declaration' of the process as a N network object (c.f. DECnet and PSI) by always maintaining a passive listen onO port 119. On successful completion of the passive listen, the channel is handed L to thread code and another passive listen is created. It is conceivable thatI another call could be made during the short period when a listen ISN'T in J progress - this will cause the IP_ACP to fire-up another server process. IO haven't added any code to check for multiple occurances of such processes (such  as using locks, etc).   H 3) Passive listens are maintained when MAXTHREADS is achieved. Calls areN accepted so that an NNTP service failure message can be sent. The call is thenM closed and the passive listen re-established. This behaviour could be changed J so that when MAXTHREADS is achieved, further passive listens are disabled,6 enabling the IP_ACP to fire-off more server processes.  C 4) Idle timeouts are used (IO$_CREATE parameter) to clear forgotten L connections. The only problem with this is that an idle connection is closedM without being able to send an NNTP service failure message. So far, I haven't N encountered any problems with this - rtass and rrn (the clients mostly used atM our site) re-establish contact without problems. Also, clients are often just F as rude, rather than sending a QUIT, they often tend to just abort the connection.   H 5) When the number of active threads falls back down to zero, the serverO terminates immediately rather than loitering for further potential connections. 1 I find this behaviour acceptable, others may not.   L 6) The server interface buffers an entire transaction for each active threadM because of the presumed limitations of mixing calls to malloc and free in AST I context (ie, I couldn't get it to work). Consequently, the stream of data O following a POST command will be buffered on the heap until "." is received and O only then will the next_function for that thread be called. Similarly, commands N such as LIST will have their outputs buffered on the heap until their function@ completes. Just make sure that the process has enough PGFLQUOTA.  K 7) This code is free of debug and trace facilities. To debug this I tend to K rely entirely upon VAX DEBUG and VMXED. The code works well as far as I can L tell, errors are handled by abandoning the threads - no in-depth analysis ofM exception codes is performed and no recovery is attempted within the confines  of the current thread.  L 8) The server code is compiled and linked as for the single-threaded version (NNTP_TCPCMU.C).  I 9) This is the line we have in our INTERNET.CONFIG for the multi-threaded  server. It appears to suffice:  E WKS:119:NEWSRV:TCP$NEWSRV:NETWRK:NETMBX,TMPMBX,PHY_IO,SYSPRV,SYSLCK:\ 9 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:K Note that SYSLCK privilege is needed due to rather strange behaviour on the I part of one of our mail protocol handlers - you probably won't need this.   N 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  --6 Keith Halewood           Janet: keith@uk.ac.liv.cs.and9 Dept. Computer Science,  Internet: keith@and.cs.liv.ac.uk  Liverpool University. K "If they're the only survivors of a nuclear holocaust then they can't be in + very good shape." - Beverly Crusher, ST:TNG 