Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!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: <4172:Jun815:28:1691@kramden.acf.nyu.edu>
Date: 8 Jun 91 15:28:16 GMT
References: <1991May31.095020.15271@colorado.edu> <24305:Jun214:50:4891@kramden.acf.nyu.edu> <1991Jun6.143453.29926@thunder.mcrcim.mcgill.edu>
Organization: IR
Lines: 25

In article <1991Jun6.143453.29926@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
> 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.

No, it does not. The only thing it turns off is local tty processing; it
will still respond to TELNET protocol negotiations. And the original
poster was setting up a server---that's telnetd, not telnet.

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

The problem is that the result isn't a standard application. How do you
expect anyone to use a server if they have to go to such lengths to make
the client? What I'm saying is that a dumb client---and a dumb server---
should be available in each vendor's distribution.

---Dan