Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: Perl Socket problem
Message-ID: <1991Jun6.143453.29926@thunder.mcrcim.mcgill.edu>
Date: 6 Jun 91 14:34:53 GMT
References: <1991May31.095020.15271@colorado.edu> <24305:Jun214:50:4891@kramden.acf.nyu.edu>
Organization: McGill Research Centre for Intelligent Machines
Lines: 33

In article <24305:Jun214:50:4891@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

> (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.  [...])

Modern telnet does precisely that when you specify a port other than
the standard telnet port to connect to.

> 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.

A lot of the telnet protocol features (like Interrupt Process, which we
saw in the text I didn't quote) need some sort of communication with
the daemon application other than the data byte-stream.  Propose an
interface....

> So people like you can't easily put together perfectly legitimate
> network applications.

Geesh.  Fire up ftp to uunet, fetch Berkeley telnet and/or telnetd, rip
out the pty code, and go to town.  What's the problem?

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu