Zweck dieser Anwendung ist die interaktive Nutzung entfernter Rechner im Textmodus (auch als remote login bezeichnet). Natürlich nutzt man auch mit anderen Anwendungen wie WWW, FTP oder E-Mail entfernte Rechner, kann allerdings dabei in der Regel keine beliebigen Programme auf den entfernten Rechnern ausführen.
Typische Anwendungsfälle für TELNET sind:
Häufig erfolgt bei Telnet nur eine sehr schwache Authentifizierung und keine Verschlüsselung der zwischen den Partnern ausgetauschten Daten. In der Regel weist nur der Klient dem Server die Kenntnis eines Paßworts nach, wobei dieses Paßwort meist im Klartext übertragen wird und so relativ leicht abgehört und mißbraucht werden kann. Der Server authentifiziert sich gegenüber dem Klienten im Normalfall überhaupt nicht.Diese Situation ist speziell in potentiell unsicheren Netzen wie dem Internet unbefriedigend bzw. absolut inakzeptabel. Daher wird Telnet in letzter Zeit für viele Aufgaben zunehmend durch andere Protokolle ersetzt, primär durch die Secure Shell (SSH), die wir uns im Kapitel 8 genauer ansehen werden.
In einer Reihe weiterer Anwendungsfälle steht TELNET "in Konkurrenz" mit anderen Protokollen:
Alternative: WWW
Alternative: SNMP (Simple Network Management Protocol), WWW
Die entfernte Nutzung eines Rechners basiert auf dem Client/Server-Konzept:
Der TELNET-Klient interagiert sowohl mit dem Nutzer (Tastatureingaben bzw. Bildschirmausgaben) als auch mit der TCP-Verbindung zum TELNET-Server. Normalerweise werden jegliche Nutzereingaben an den Server geschickt und alle von ihm empfangenen Daten auf dem "Nutzerterminal" dargestellt. Der TELNET-Server dagegen bedient die Applikation, die wir entfernt (remote) nutzen. In Unix-ähnlichen Betriebssystemen erfolgt dies über sog. Pseudoterminals.
Ein Grundanliegen von TELNET war die vollständige
Systemunabhängigkeit, so daß sich jeder Host mit jedem "versteht",
unabhängig von den angeschlossenen Endgeräten (Terminals).
Daher wurde ein sogenanntes network virtual terminal (NVT) - ein
zeichenorientiertes Gerät mit Ein- und Ausgabemöglichkeit - mit
einer bestimmten Grundfunktionalität eingeführt. Sowohl Klient
als auch Server sind dafür verantwortlich, ihre Fähigkeiten auf
diese Grundfunktionalität abzubilden.
Als Zeichensatz wird der 7-Bit-Code NVT ASCII
verwendet (das höchstwertige Bit jedes Bytes ist 0).
Damit ist eine Basis für die Verständigung zwischen Klient und Server geschaffen. Es existieren jedoch meist etliche optionale Fähigkeiten (z.B. Unterstützung eines bestimmten realen Terminal-Typs), so daß beide Seiten zu Beginn einen gemeinsamen Satz dieser Fähigkeiten aushandeln müssen (option negotiation). Dies erfolgt vollkommen symmetrisch, d.h., jede Seite kann die andere veranlassen, eine bestimmte Option ein- bzw. auszuschalten.
Wir haben gesehen, daß die TELNET-Verbindung nur aus einer einzigen TCP-Verbindung besteht. Die Übertragung von Protokollelementen (z.B. zur Optionsaushandlung) erfordert daher deren Unterscheidung von den Nutzdaten. Zu diesem Zweck wird jedem Protokollelement ein Byte mit dem Wert 255 vorangestellt, das die Bedeutung interprete as command (IAC) besitzt.
Im wesentlichen werden vom TELNET-Klienten/Server die folgenden Übertragungsmodi unterstützt:
Dies ist der Standardmodus, wobei jedes vom Nutzer eingegebene Zeichen in einem eigenen Paket über das Netzwerk zum Server geschickt wird. Für das Echo ist der Server verantwortlich, indem er das Echo der entfernt genutzten Anwendung zum Klienten schickt (beispielsweise bei einer Shell jedes gesendete Zeichen). Einerseits verursacht dieses Verfahren dadurch natürlich eine relativ große Netzlast, andererseits lassen sich einige Anwendungen (z.B. bildschirmorientierte Editoren wie Vi und Emacs) nur mit diesem Mode betreiben.
Die Grundidee dieses Modus ist die geschlossene Übertragung kompletter Zeilen. Dies vermindert gerade auf Verbindungen mit geringer Bandbreite und/oder hoher Verzögerungszeit erheblich die Netzlast. Der Klient muß daher ein lokales Echo erzeugen und eine Minimalfunktionalität zum Editieren einer Zeile zur Verfügung stellen. Allerdings ist dieser Modus nur bei zeilenorientierten Anwendungen sinnvoll, z.B. zur Bedienung einer Shell, in der zeilenorientierte UNIX-Kommandos (u.a. Editoren wie ed und sed) ausgeführt werden.
Sowohl Klient als auch Server können eine der folgenden Anforderungen an die jeweilige Gegenseite richten:
Eine Anforderung auf Aktivierung einer Option kann von der Gegenseite angenommen oder abgewiesen werden (Fälle 1 und 2), eine Anforderung auf die Deaktivierung darf dagegen nicht abgelehnt werden (Fälle 3 und 4). Daraus ergeben sich die nachfolgend dargestellten Szenarien:
Die Aushandlung von Optionen erfordert also die Übertragung von 3 Bytes: das IAC-Byte gefolgt von der Anforderung auf (De)Aktivierung (WILL, DO, WONT, DONT) und die eigentliche Option. Hier sind einige wichtige Optionen:
Sender Empfänger Beschreibung WILL -->
<-- DOSender möchte eine Option aktivieren; Empfänger stimmt zu WILL -->
<-- DONTSender möchte eine Option aktivieren; Empfänger lehnt ab DO -->
<-- WILLSender möchte, daß der Empfänger eine Option aktiviert; Empfänger stimmt zu DO -->
<-- WONTSender möchte, daß der Empfänger eine Option aktiviert; Empfänger lehnt ab WONT -->
<-- DONTSender möchte eine Option deaktivieren; Empfänger muß zustimmen DONT -->
<-- WONTSender möchte, daß der Empfänger eine Option deaktiviert; Empfänger muß zustimmen
Optionscode Name Beschreibung 1 echo Entscheidung, welche Seite ein Echo ausführt 3 suppress go ahead NVT folgt normalerweise einem Halbduplexprotokoll. Vollduplex-Endgeräten wird damit ermöglicht, auf das Signal GO AHEAD zu verzichten. 5 status ermöglicht die Verifikation des TELNET-Status aus Sicht der Gegenseite 24 terminal type Terminalemulatoren (z.B. xterm) unterstützen häufig verschiedene Modi. Der Klient sendet dem Server eine Liste verfügbarer Modi, von denen dieser einen auswählt. 32 terminal speed Applikationen sind häufig für bestimmte Übertragungsraten (Modem) optimiert. Mit der Option wird diese Funktionalität auch über TELNET-Verbindungen zur Verfügung gestellt. 34 linemode Übertragungsmodus Linemode einstellen 36 environment variables Mechanismus zur Übertragung von Umgebungsvariablen vom Klienten zum entfernt genutzten Rechner
Name Code Beschreibung EOF 236 end-of-file, Fileendekennzeichen SB 250 subnegotiation begin. Einige Optionen erfordern mehr als eine einfache (De)aktivierung. Ein Beispiel ist die Spezifikation des Terminal-Typs. Dessen Bezeichnung ist in Form einer ASCII-Zeichenkette zu übertragen. Derartige Optionen werden in zwei Schritten ausgehandelt. Zuerst einigt man sich darauf, den bzw. die Parameter zu "diskutieren", und anschließend findet die Parameter-Diskussion in einer sog. subnegotiation statt, die jeweils mit dem Kommando SB eingeleitet und mit dem Kommando SE (subnegotiation end) beendet wird. SE 240 subnegotiation end, Endekennzeichen der subnegotiation einer Option AYT 246 are you there?, Verbindungstest GA 249 go ahead, Flußsteuerung im Halbduplex-Betrieb WILL 251 Optionsaushandlung, siehe oben WONT 252 Optionsaushandlung, siehe oben DO 253 Optionsaushandlung, siehe oben DONT 254 Optionsaushandlung, siehe oben IAC 255 Datenbyte mit dem Wert 255