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