nsayer@uop.edu (Nick Sayer) (04/11/91)
This has no doubt been brought up before. It is the case at this campus that the cost of moving bytes through our gateway is much, much higher than the cost of disposing of duplicate articles. Under these circumstances, it makes more sense to pass batches of news in the same way as happens over uucp links. Under these circumstances, would it not make sense to have a command to pass such batches? I see this scenario: a /usr/spool/nntp has uniquely named files that contain the output of a (modified) sendbatch script. That is, "#! cunbatch" and a compressed mess. A nnbtchxmit program is invoked by cron periodically to look for and move these files. If a file fails in transmission, it will stay in /usr/spool/nntp. There are two ways to manage the transmission of files: 1. The transmitter sends "rbatch <bytes>". The receiver sends a partial-success/continue result code, and sets up an 8 bit raw channel. It then receives the proper number of bytes, returns to cooked I/O, and sends a success result code. 2. The transmitter sends "rbatch <bytes> <socka>". The receiver sends a partial-success/continue result code with a "<sockb>". The transmitter and receiver set up secondary communications between the two sockets much like ftp/ftpd do. This allows for interrupting commands and/or result codes. Of the two, I prefer #1. I wouldn't mind doing the coding, but I don't want to reinvent the wheel, or do something that is clearly not a benificial thing. Comments are welcome.