Perl Socket problem

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Sun Jun 9 01:28:16 AEST 1991


In article <1991Jun6.143453.29926 at thunder.mcrcim.mcgill.edu> mouse at thunder.mcrcim.mcgill.edu (der Mouse) writes:
> In article <24305:Jun214:50:4891 at kramden.acf.nyu.edu>, brnstnd at 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



More information about the Comp.unix.questions mailing list