|
Aufbau der Telnet Verbindung mit UDP, TCP/IP
Der Aufbau der Telnetverbindung besteht aus den Phasen a) Aufruf des Telnet
Hostrechners mit UDP, b) TCP/IP Synchronisation, c) Vereinbarung von Telnet
Parametern, d) Authentisierung mit Login und Password, e) Äbertragung von Daten
über User und Telnet sowie der Eingabeaufforderung des Hostrechners. SatzID DLä Daten -------------------------------------------------------------------------------- 2A Cl.Adr=84 C3 16 30 DNSAdr=84 C3 14 0D 2C 000101000001 000000000100 05 WRA05 03 URZ 0D UNI-WUPPERTAL 02 DE 0000010001 9E DNSAdr=84 C3 14 0D Cl.Adr=84 C3 16 30 D8 000185800001 000100050006 05 WRA05 03 URZ 0D UNI-WUPPERTAL 02 DE 0000010001 C00C000100010001 51800004 84 C3 14 90 C016000200010001 51800005 02 NS C016C016000200010001 51800006 03 NS3 C016C016000200010001 51800015 07 WS-HAM1 06 WIN-IP 03 DFN C024C016000200010001 5180000A 07 WS-MUE1 C073C016000200010001 5180000D 02 NS 04 RIPE 03 NET 00C048000100010001 51800004 84C3140D C059000100010001 51800004 84C31403 C06B00010001000070 43 230004C1AE4B92C08C 000100010000 CC4A0004C1AE4BA6C0 A2001C00010000 A95E00102001061002 40000000530000 00000193C0A200010001 000155B10004 C10000C1 SatzID Sequ.Nr. Bestät.Nr. FeCl. FeSe Flag DLä Daten -------------------------------------------------------------------------------- 2C 46 50 32 A4 00 00 00 00 2238 02 08 02 04 05 b4 01 01 04 02 A0 00 42 71 AB 46 50 32 A5 EF42 12 04 02 04 05 b4 2D 46 50 32 A5 00 42 71 AC 2238 10 A1 00 42 71 AC 46 50 32 A5 EF42 18 0C FFFD18 FFFD20 FFFD23 FFFD24 2E 46 50 32 A5 00 42 71 B8 222C 18 03 FFFB18 A2 00 42 71 B8 46 50 32 A8 EF3F 10 2F 46 50 32 A8 00 42 71 B8 222C 18 09 FFFC20 FFFC23 FFFC24 A3 00 42 71 B8 46 50 32 B1 EF42 10 A4 00 42 71 B8 46 50 32 B1 EF39 10 06 FFFA1801 FFF0 30 46 50 32 B1 00 42 71 BE 2226 18 0A FFFA1800 ANSI FFF0 A5 00 42 71 BE 46 50 32 BB EF42 18 0F FFFB03 FFFD01 FFFD1F FFFB05 FFFD21 31 46 50 32 BB 00 42 71 CD 2217 18 03 FFFD03 A6 00 42 71 CD 46 50 32 BE EF42 10 32 45 50 32 BE 00 42 71 CD 2217 18 0C FFFB01 FFFC1F FFFE05 FFFC21 A7 00 42 71 CD 46 50 32 CA EF36 10 A8 00 42 71 CD 46 50 32 CA EF42 18 1E FFFE01 FFFB01 0D0A0D0A IRIXb(WRA05) 0D0A0D000D0A0D00 33 46 50 32 CA 00 42 71 EB 21F9 18 03 FFFC01 A9 00 42 71 EB 46 50 32 D0 EF3F 18 07 LOGIN:b 34 46 50 32 D0 00 42 71 F2 21F2 18 03 FFFD01 AA 00 42 71 F2 46 50 32 D0 EF42 10 SatzID Sequ.Nr. Bestät.Nr. FeCl. FeSe Flag DLä Daten -------------------------------------------------------------------------------- 35 46 50 32 D0 00 42 71 F2 21F2 18 08 EA0724 0D0A AB 00 42 71 F2 46 50 32 D8 EF3A 18 06 EA0724 36 46 50 32 D8 00 42 71 F8 21EC 10 AC 00 42 71 F8 46 50 32 D8 EF42 18 0B PASSWORD: 37 46 50 32 D8 00 42 72 03 21E1 18 09 HANSGEO 0D0A AD 00 42 72 03 46 50 32 E1 EF42 18 02 0D0A 38 46 50 32 E1 00 42 72 05 21DF 10 SatzID Sequ.Nr. Bestät.Nr. FeCl. FeSe Flag DLä Daten -------------------------------------------------------------------------------- AE 00 42 72 03 46 50 32 E1 EF42 18 CC IRIX Release 6.5 IP32 WRA05 0D0A Copyright 1987-1999 Silicon Graphics, Inc. All Rights Reserved. 0D0A Last login: Fri Feb 27b 13:57:23 MET 2004 By UNKNOWN`uni- at-home56.dialin. uni-wuppertal.de 0D0A Ihr DISPLAY zeigt n A5 ach: uni-at-home56.dialin.uni- wuppertal.de:0 0D0A Ihre Email-Adresse ist: EA0724`stud.uni- wuppertal.de 0D0A Environments:b 0D0A - Uni: 990812 0D0A - Mail: 990812 0D0A EA0724 WRA05 1%b 39 46 50 32 E1 00 42 73 76 206E 10 Die oben dargestellten Phasen des Aufbaus einer Telnetverbindung sind durch doppelte Leerzeilen voneinander getrennt. Für die erste Phase, Aufruf des Telnet Hostrechners, gelten die Überschriften nur bezüglich der ID, Datenlänge, Daten. An Stelle der Sequenz- und Bestätigungsnummern sind hier die IP Adressen für Client und DN Server gesetzt worden, die unter PPP/IPCP zugeteilt wurden. Die IP Addresse des Client bleibt über die gesamte Session gleich. Für den auf UDP folgenden TCP Dialog gibt die UDP Bestätigung des Servers eine neue IP Adresse hex. 84 C3 14 90. Telnet hat serverseitig feste Portnummern: 0035 für UDP und 0017 für TCP. Die Portnummern des Clients gibt dieser in seinen ersten Anforderungspaketen bekannt (hier hex. 042c für UDP und 0405 für TCP). Der oben dargestellte Dialog enthält nicht die vollständigen Daten der IP, UDP, TCP Headersätze, sondern nur einige für den Aufbau der Telnetverbindung relevante Kennzeichen und Felder der Headersätze. Der Datenteil der Pakete ist vollständig wiedergegeben. Die Sätze, die der Client sendet, haben die Satz-ID 2A u. folgende. Die Sätze, die der Server sendet, haben die Satz-ID 9E u. folgende. Da die Headersätze erhebliche Redundanz aufweisen, die z.B. durch die Van Jacobson Headerkompression wieder beseitigt werden kann, wird hier auf vollständige Darstellung der Headersätze verzichtet. Die Satzstrukturen sind datailliert in den RFC's 791 (IP), 792 (ICMP), 793 (TCP), 768 (UDP), und in der Literatur, z.B. G.M. Glaser, M.Hein, J. Vogel, TCP/IP, 2. Aufl. München 1997, oder in UNIX-Rechnernetze, DATACOM, 1994, beschrieben. Über den neuesten Stand der Werte von Kennziffern gibt das "Assigned Numbers" RFC 790 Auskunft. Die obigen Satzauszüge sind in hexadezimaler Form wiedergegeben. Texte in den Daten sind alphabetisch dargestellt. Leerstellen an Textenden sind als b gekenn zeichnet. Die Leerstellen zwischen hexadezimal dargestellten Zeichen dienen nur der Gliederung und Übersichtlichkeit. Sie sind im Datenstrom nicht enthalten. Da UDP, mit dem der Telnet Verbindungsaufbau beginnt, nicht ein verbindungs orientiertes Protokoll wie TCP ist, besitzt es, auser dem IP-Header, nur einen 8 Byte UDP-Header, mit dem Portnummern, für Telnet fest 0035 und für den Client z.B. 042C übertragen werden. UDP arbeitet mit den von PPP zugewiesenen IP Adressen für Client und Server, die mit den Portnummern den Datenweg identifizieren. Das erste UDP Paket enthält den Aufruf des Hostrechners mit dessen Bezeichnung. Die umfangreiche Bestätigung des Servers enthält Angaben zu den Servern, sowie die neue Server-IP-Adresse hex. 84 c3 14 90. Der Aufbau der TCP Verbindung beginnt mit Senden eines Synchronisationssatzes vom Client. Das Flag (Wert 02) kennzeichnet den Vorgang als Synchronisation. Wert 12 kennzeichnet Synchronisationsbestätigung. Wert 10 kennzeichnet ein ACK. Wert 18 ist ACK+Datentransfer. Weitere Kennzeichen sind Verbindungsreset (Wert 04) und Verbindungsende (Wert 01). Die TCP Verbindung wird durch die Eröffnung einer "Datenbuchhaltung" mit dem Austausch von "Anfangskontoständen" definiert. Der Synchronisationssatz des Client sendet als Kontostand eine 4 Byte Sequenznummer sowie ein 2 Byte "Daten- Fenster" für die Menge zu erwartender Daten. Der Server Bestätigt die Synchronisation durch Addieren von 1 zur Seqenznummer des Client, die für ihn Bestätigungsnummer ist, und Senden eines eigenen Anfangskontostandes durch seine Sequenznummer sowie eines Fensterwertes.Die Sequenznummern der einen Seite werden von der Gegenseite jeweils als Bestätigungsnummern geführt und die Längen empfangener gültiger Daten hinzuaddiert.So sind Wiederholungsanforderungen bei fehlerhafter Übertragung möglich, indem der "alte Kontostand", bis zu dem die Übertragung erfolgreich war, als Bestätigunsnummer zurückgesendet wird. Die Gegenseite kann mit der Übertragung bei diesem "Kontostand" aufsetzen. Vom Empfänger als gültig akzeptierte Daten werden mit dem Längenwert vom "Fenster" subtrahiert. Damit wird signalisiert, daß die Daten richtig übertragen wurden und aus dem Wiederholungspuffer des Senders gelöscht werden können. Der Client subtrahiert fortlaufend vom "Fenster" (FeCl). Der Server setzt das "Fenster" (FeSe) laufend zurück auf den Anfangswert. Auch der Client muß daten mengenbedingt den Fensterwert wieder zurücksetzen. Dieses Verfahren der Datenübertragungskontrolle macht TCP zu einem "verbindungs- orientierten" Protokoll. Das Verbindungsende wird ebenfalls durch Senden von Terminierungspaketen vereinbart. Das Ende der Synchronisationsphase wird vom Client durch Übertragen der für jede Seite gültigen Sequenznummer/Bestätigunsnummer sowie des Fensteranfangs- wertes bestätigt, nachdem die Seqenznummer des Servers ebenfalls um 1 erhöht wurde. Damit sind die "Anfangskontostände" für die Datenübertragung vereinbart. In der Synchronisationsphase werden ferner die maximalen Segmentlängen für die Datenübertragung vereinbart. Die 8 bzw. 4 Byte Werte sind Bestandteil eines um 2 bzw. 1 Datenwort erweiterten TCP Headers. Z.B. wird eine max. Segmentlänge von hex. 05B4, d.h. 1460 Byte vereinbart. Mit PPP wurde bereits eine max. Paketlänge von 250 Byte vereinbart. Längere Datensegmente als 244 Byte (+ 5 Byte PPP Frame = 249 Byte) müssen fragmentiert werden. Das Datenbeispiel enthält bereits zwei fragmentierte Datensegmente mit der UDP Bestätigung und mit der Übertragung der User und Telnet Daten sowie der ersten Telnet Eingabeaufforderung. Hier wird ein Anfangsfragment von hex. F4 = 244 Byte - 40 Byte IP und TCP Header = 204 Datenbyte empfangen, sowie ein Folgefragment von hex. B9 = 185 Byte - 20 Byte IP Header (Folgefragmente enthalten keine TCP Header) = 165 Byte Daten. Diese Paket- und Segmentlängen machen für einen 8 Bit Prozessor die Prüfung und Bearbeitung der einzelnen Datenpakte mit einem 1 Byte Schleifenzähler (bis 256) möglich. Der zusätzliche Fragmentierungsaufwand fällt bei Telnet ausschließlich für den größeren Serverrechner an. In der dritten Phase werden Telnet Parameter in den mit FF beginnenden Befehls- folgen vereinbart. FF kennzeichnet ein nachfolgendes Telnetkommando. F0 bis FE sind Befehlscodes. 0 bis 24 sind Telnetoptionen. Es werden Parameter zu Echo, Abort, Flow Control, Terminal Type und Terminal Speed vereinbart. Einzelheiten zu dieser Kommandosprache werden in der o.g. Literatur erläutert. In der vierten Phase werden LOGIN und PASSWORD eingegeben und bestätigt. Danach werden in der fünften Phase Benutzer- und Systemdaten an den Client übermittelt, sowie der Eingabepromt WRA05 1% des UNIX (IRIX) Systems, auf dem via Telnet gearbeitet werden soll, ausgegeben. Der nach Aufbau dieser Verbindung mögliche Dialog mit IRIX besteht einerseits aus den Tastatureingaben der Unixkommandosprache seitens des Clients und andererseits aus dem Empfang und Display von Meldungen, Dateiverzeichnissen und Dateiinhalten gesendet vom UNIX System des Serverrechners. Bei Tastaureingaben wird jedes Zeichen einzeln übertragen. D.h. ein Tastaturzeichen wird in 20 Byte IP Header + 20 Byte TCP-Header + 5 Byte PPP-Frame und FCS verpackt. Der Server sendet sodann eine Bestätigung (Flag 10=ACK) mit IP und TCP Headern + PPP Frame und FCS. Dann wird das Tastaturzeichen in gleicher Verpackung zur Bestätigung zurückgesendet. Der Client sendet nochmals ACK (Flag 10) mit 45 Byte Headern und PPP Frame zur Bestätigung, daß das zurückerhaltene Zeichen dem Originalzeichen entspricht. Somit werden 2x das Tastaturzeichen selbst, zuzüglich 4x IP, TCP Header + PPP Frame = 182 Zeichen zur "Absicherung" der Übertragung nur eines Tastaturzeichens über das Netz gesendet. Wird dabei nur eines der 182 Byte zerstört, ist die Übertragung des einen Tastaturzeichens nicht mehr erfolgreich. In der Praxis treten dabei allerdings kaum Verluste auf. Die Quote der Tastatureingabefehler, bei denen die Eingabe wiederholt werden muß, ist unverhältnismäßig höher. Dieser overheadintensive Bestätigungsformalismus mit Echo wird nur für die vom Client gesendeten Tastatureingaben vorgenommen. Die vom Server an den Client gesendeten Meldungen, Dateiverzeichnisse und Dateiinhalte werden vom Client nur durch ein einfaches ACK Paket (Flag 10) bestätigt. Der Serverrechner ist jedoch großzügig im Senden von Datenwiederholungen auch ohne Anforderung. Insofern be steht das Problem, aus dem erhaltenen Datenvolumen die benötigten Daten heraus zusortieren, was anhand der Sequenz- und Bestätigungsnummern möglich ist. Eine Wiederholungsaufforderung wird gegeben, indem der Client ein ACK Paket mit der Bestätigungsnummer auf dem Stand vor dem letzten (vorletzten) Empfang an den Server sendet. Übernimmt MTEC4 die Rolle des Servers und wird z.B. von einem PC angerufen, um eine Telnet Verbindung herzustellen, gilt der gleiche Ablauf mit vertauschten Rollen. Mondenias MTEC4 Kleinrechner wickelt diesen UDP/TCP/IP Protokoll- und Telnet betrieb mit einem Codieraufwand von etwa 1KB zusätzlich zu den bereits von PPP benutzten Protokoll- und Senderoutinen von etwa 400 Byte ab. Damit werden auch für einen 1MHz Rechner bei 9600 Baud noch annehmbare Bedienungs- und Über tragungszeiten erreicht. |
| HOME |