Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!paperboy!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: Perl Socket problem
Message-ID: <24305:Jun214:50:4891@kramden.acf.nyu.edu>
Date: 2 Jun 91 14:50:48 GMT
References: <1991May31.095020.15271@colorado.edu>
Organization: IR
Lines: 27

In article <1991May31.095020.15271@colorado.edu> frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes:
  [ random network code ]
> This is what opens the socket and gets it running.. Everthing happens 
> inside this while loop.  Now this is the problem.  If someone connected to the
> server from outside presses control-C it locks up the connection.

By ``connected'' you mean a telnet connection. The problem is that
TELNET is a two-way communications protocol, and when the telnet client
says ``Hey, I received a ^C, and I know that's an interrupt, so what are
you going to do about it?'' it expects an answer before it produces
further output. If you want your server to talk correctly to telnet,
you'd better support the TELNET protocol.

(You might ask at this point why every dumb little network application
has to support TELNET. The answer is that vendors don't realize the
virtue of a pure communications program---something that sets up a
connection but doesn't burden you with one protocol or another. So users
are going to use the telnet program even when the TELNET protocol is
entirely inappropriate. You might also ask why the standard TELNET
protocol daemon, namely telnetd, is so overloaded with network and pty
support. The answer, again, is that vendors don't realize the virtue of
a pure TELNET daemon---something that interprets the protocol but
doesn't assume that your application is a TCP login. So people like you
can't easily put together perfectly legitimate network applications.
Don't you feel lucky that the vendors are so smart?)

---Dan