Date: Mon, 27 Sep 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #250
To: tcp-group-digest
TCP-Group Digest Mon, 27 Sep 93 Volume 93 : Issue 250
Today's Topics:
SMTP timeout and Unix sendmail
tcp slip conncetion
What to put on a CD-ROM?
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sun, 26 Sep 1993 10:43:07 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: SMTP timeout and Unix sendmail
To: tcp-group@ucsd.edu
All right: the verdict seems to be unanimous, and you can all stop
inundating me with mail saying that modifying NOS so that it will
reset an incoming SMTP session when another SMTP session is started
by the same host is a bad idea. I tend to agree with the comment
that this behavior of sendmail is "stupid but legal," which sums it
up quite nicely.
The comment (from Andy, I think) about using an alarm does not seem
like a good idea. This would lead to all kinds of synchronization
problems. For example, NOS gets very upset when the process which
has posted an alarm no longer exists when the alarm goes off, as
Walt keeps finding out in the OS/2 port. Alarms are really intended
for more critical tasks, where you need something to get attention
from the processor asynchronously. An old socket killer might be
handled more easily as a separate process in the NOS task list, much
on the model of the garbage collector. The idea would be to make an
automatic process (a daemon) who does just what the user would do by
typing "tcp reset..." at the keyboard. It would be a lot easier to
do it this way without introducing instability into NOS. The TCP
code would need to be modified only to set a field in the TCP
control block when each frame was transmitted or received, and this
would be trivial.
-- Mike, mikebw@ids.net
N1BEE @ WA1PHY.#EMA.MA.USA.NA
------------------------------
Date: 26 Sep 1993 22:22:22 GMT
From: "Don Buehler" <ROHVM1.MAHDWB@CDCMVS1.ROHMHAAS.COM>
Subject: tcp slip conncetion
To: TCP-Group@UCSD.Edu
Paraloid EXL Additives
.
I am wondering what software is available for an ibm slip connection for mail
and usenet mail processing. The slip software dloads mail to the disk, but it
all must then be read by a word processor. Are there any programs that will wo
rk with the slip software to enable for elaborate mail reading/processing? Pos
sibly even muiltiple mailboxes?
If possible, please reply to this in email or at least cc: your reply from the
digest into an email message to me. Thanks in advance.
If there is a better conference that you could recomend for me to ask this ques
tion, then please, by all means, let me know where. Thanks a million and a hal
f.
-Don Buehler
Don Buehler
ROHM & HAAS COMPANY
(215) 592-3385 / Fax: (215) 592-2285
PROFS:MAHDWB @ ROHVM1 / MCI Mail: 395-3424
------------------------------
Date: Sun, 26 Sep 1993 20:44:50 EDT
From: "Russell Nelson" <nelson@crynwr.com>
Subject: What to put on a CD-ROM?
To: tcp-group@ucsd.edu
I'm putting together a CD-ROM of packet driver software. I see all
these different versions of NOS being published, but I've only ever
run Phil's version. Could someone tell me what versions of NOS to
put on it besides ucsd.edu:hamradio/packet/tcpip/ka9q/rcsdsrc.zip?
--
-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
------------------------------
End of TCP-Group Digest V93 #250
******************************
******************************