tcp – Why Telnet is Considered a Protocol and Not Just a TCP Send/Echo Program

Protocolstcptelnet

This is more like a conceptual question. I need some clarifications.

Today I was learning some socket programming stuff and wrote a simple chat server and chat client based on Beej's Guide to Network Programming. (chat server receives clients message and send messages to all the other clients)

I copied the chat server and I wrote my own chat client.

The chat client is just a program to send stdin input to server and print socket data from server.

Later I noticed that the guide says I can just use telnet to connect to the server. I tried and it worked.

I was unfamiliar with telnet and for a long time I don't know what exactly it is.

So now my experience confuses me:

Isn't telnet just a simple TCP send/echo program? What makes it so special to be a protocol thing? My dumb chat client program doesn't create a [application] protocol.

From Wikipedia Communication_protocol :

In telecommunication, a communication protocol is a system of rules
that allow two or more entities of a communications system to transmit
information via any kind of variation of a physical quantity.

What rules does Telnet create? telnet host port, open a TCP stream socket for raw input/output? That's not a rule.

Best Answer

Telnet is defined in RFC 854. What makes it (and anything else) a protocol is a set of rules/constraints. One such rule is that Telnet is done over TCP, and assigned port 23 - this stuff might seem trivial, but it needs to be specified somewhere.

You can't just send whatever you want, there are limitations and special meaning to some things. For example, it defines a "Network Virtual Terminal" - this is because when telnet was established, there could be many different terminals: A printer, a black/white monitor, a color monitor that supported ANSI codes, etc.

Also, there's stuff like this:

In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgments; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON'T and WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood.

In modern times, most of the stuff isn't really that important anymore (then again, telnet as a protocol isn't being used much anymore, not just because it lacks security) so in practice it boils down to send/echo unless you have to actually interface with terminals.

Related Question