Dieser Leitfaden erklärt X.25 Networking, indem er X.25 mit Netzwerken vergleicht, mit denen der Leser möglicherweise vertraut ist, nämlich TCP/IP-Netzwerke (wie das Internet) und das Public Switched Telephone Network (PSTN).

 

Überblick zum X.25 Leitfaden

Was ist ein X.25-Netzwerk?

Ein X.25-Netzwerk stellt ein Mittel zur Verfügung, mit dem eine X.25 DTE (ein Terminal oder Host jeglicher Art) Daten mit einem oder mehreren anderen X.25-Hosts auf der anderen Seite des Netzwerks austauschen kann.

D1 X.25 Network

Daten werden innerhalb einzelner Pakete übertragen - X.25 wird oft als Packet Switching Protocol bezeichnet. Dies macht es ähnlich wie ein TCP/IP-Netzwerk - der Unterschied besteht darin, dass IP-Netzwerke ein verbindungsloses Protokoll verwenden: Jedes Paket wird entsprechend den Informationen innerhalb dieses Pakets weitergeleitet (typischerweise unter Verwendung der Zieladresse). Im Gegensatz dazu ist X.25 ein verbindungsorientiertes Protokoll: Die vom Netzwerk verwendeten Routinginformationen werden nur in den Paketen übertragen, die für den Verbindungsaufbau verwendet werden; danach sind keine Adressierungsinformationen erforderlich. Dies bedeutet jedoch, dass die X.25-Netzwerk-Switching-Knoten im Gegensatz zu IP-Routern jede Verbindung kennen müssen.

X.25 Layers

Das X.25-Protokoll ist in 3 Schichten (oder Levels) unterteilt; TCP/IP hingegen ist in 4 Schichten unterteilt.

Layer Beschreibung X.25 TCP/IP-Äquivalenz
1 Physikalische Schicht V.24, X.21, V.35, etc Wie X.25 und andere, welche normalerweise nicht von X.25 verwendet werden (zu viele, um sie zu erwähnen).
2 Data Link Layer LAPB Viele, wie PPP, SLIP, Cisco HDLC, etc. und sogar X.25 selbst!
3 Network Layer X.25 PLP IP
4 Transport Layer (none) TCP or UDP
  Jede dieser Schichten ist unabhängig. Die Physische Schicht beinhaltet den mechanischen und elektrischen Aspekt der Kommunikation - also die Verkabelung. Die X.25 Data Link Layer stellt die zuverlässige Verbindung zwischen der DEE und der DCE (oder dem Netzwerk) her, und das X.25 Packet Layer Protocol (PLP) liefert die notwendigen Informationen, um eine Verbindung über das Netzwerk herzustellen und aufrechtzuerhalten.

 

 

D2 X.25 Layers

Es ist wahrscheinlich am nützlichsten, sich die Schicht 1 als die physikalische Verbindung zum Netzwerk NTU oder Modem vorzustellen, die Schicht 2 als die logische Verbindung zwischen der DEE und dem lokalen Netzwerk-Switching-Knoten und eine virtuelle Schaltung der Schicht 3 als die Verbindung zur entfernten DEE.

X.25 Adressen

Eine X.25 Network User Address (NUA) ist ähnlich wie eine Telefonnummer, besteht aus einer Zeichenkette und kann bis zu 15 Ziffern lang sein. Die NUA in einem typischen Netzwerk ist 12 Stellen lang, mit weiteren 2 Stellen für die Subadresse.

Die X.25 DTE-Adresse wird oft als Network User Address (NUA) bezeichnet, obwohl die NUA streng genommen die Basisadresse ist, die einem Teilnehmer von einem Netzwerk zugewiesen wird, ohne die Subadresse.

Das Format der Adressen für öffentliche Netze ist in X.121 festgelegt.

Die ersten 4 Ziffern werden als DNIC bezeichnet, das das jeweilige Netzwerk identifiziert. Die restlichen Ziffern werden dann nach Ermessen des Netzbetreibers vergeben - so verwendete beispielsweise das BT-PSS-Netz der 80er Jahre in Großbritannien ein Nummerierungssystem mit einer 3-stelligen Vorwahl (die der Vorwahl des Telefonnetzes entsprach) und einer 5-stelligen Teilnehmernummer, und für die Subadresse standen weitere 2 Ziffern zur Verfügung.


X.25 Zieladressen bei ausgehenden Anrufen

Viele Netze erwarten bei einem Anruf, dass die vollständige Adresse geliefert wird, einschließlich des DNIC.

Andere Netze benötigen den DNIC nicht für Anrufe innerhalb des Netzes, aber wenn ein Anruf in ein anderes Netz erfolgt, wird vor dem DNIC eine Escape-Ziffer benötigt (genau wie beim Hinzufügen der Vorwahl bei der Wahl einer Telefonnummer) - deshalb sind die meisten X.25-Adressen auf 14-stellig begrenzt, um Platz für das Escape-Zeichen zu schaffen.


X.25 Zieladressen bei eingehenden Anrufen

Viele Netzwerke stellen die vollständige angerufene Adresse in einem Paket für eingehende Anrufe zur Verfügung; andere halten die Basis-NUA zurück und geben nur die Subadresse an, mit der Begründung, dass der X.25-Host nicht wissen muss, was seine eigene Adresse ist.


X.25 Anrufen von Adressen bei ausgehenden Anrufen

Da das Netzwerk bereits weiß, wie die Teilnehmeradresse lautet, ist es nicht immer notwendig, dass eine X.25 DEE bei einem ausgehenden Anruf eine eigene Adresse angeben muss. Das Netzwerk fügt dann das Feld Calling Address ein, bevor es das Paket über das Netzwerk an die entfernte DEE weiterleitet.

Bei der Verwendung einer Calling Sub-Address hängt es vom Netzwerk ab, ob die gesamte Adresse oder nur die Subadresse angegeben werden soll.

Virtuelle Schaltungen

X.25 Der Datentransfer findet im Rahmen von Verbindungen statt, die als Virtual Circuits bezeichnet werden. Es gibt 2 Arten von virtuellen Schaltungen:

  • Switched Virtual Circuit (SVC)
  • Permanent Virtual Circuit (PVC)

Ein X.25 SVC ist einem Telefonanruf sehr ähnlich - ein Teilnehmer initiiert die Verbindung (der "anrufende" Teilnehmer - oder "Client", um TCP/IP-Terminologie zu verwenden), und der andere Teilnehmer erhält die Verbindung (der "angerufene" Teilnehmer oder "Server"). Der Client liefert die Adresse des Servers, ähnlich wie jemand, der einen Telefonanruf tätigt, die Telefonnummer des Angerufenen wählen muss. Ein X.25 SVC ist daher ähnlich wie eine TCP/IP-Verbindung.

 X.25 Geswitchte virtuelle Schaltungen (SVC)

X.25 SVCs sind TCP-Verbindungen sehr ähnlich und können für die gleichen Zwecke verwendet werden.

Wie bereits erwähnt, ist die X.25-Datenübertragung paketorientiert (anstatt streamenbasiert wie TCP). Dies ermöglicht eine Vielzahl von Anwendungen, ohne dass eine weitere Verkapselungsschicht erforderlich ist. Dadurch ist die Datenübertragung über X.25 bei der Entwicklung eines Anwendungsprogramms einfach zu implementieren.

Call Establishment

Ein Switched Virtual Circuit wird durch eine DEE initiiert, die ein Call Request Paket an das Netzwerk sendet; das Netzwerk richtet dann eine virtuelle Verbindung zu einer DEE auf der anderen Seite des Netzwerks ein, wo das Paket bei der angerufenen DEE als Incoming Call Paket erscheint.

Die angerufene DTE kann den Anruf dann annehmen, indem sie ein Call Accept sendet - dieses wird der ursprünglich anrufenden DTE als Call Connect Paket präsentiert.

Alternativ kann die angerufene DEE den eingehenden Anruf ablehnen, indem sie ein Clear Request Paket sendet.

Data Transfer

Sobald ein Anruf angenommen wurde, kann die Datenübertragung beginnen. Im Gegensatz zu TCP/IP, bei dem es eine 3-Wege-Sequenz für den Verbindungsaufbau gibt, kann die Gerufene DEE ein Datenpaket unmittelbar nach dem Senden des Rufannahmepakets übertragen. Die Calling DEE kann Datenpakete unmittelbar nach Erhalt des Call Connect Pakets senden. Die Datenübertragung ist vollduplex, so dass entweder der Angerufene oder der Anrufer sie je nach Art der Anwendung initiieren kann (die meisten Anwendungsprotokolle sind in der Praxis halbduplex, so dass es ungewöhnlich wäre, dass sowohl die Angerufene als auch die Anrufer-DEEs so schnell wie möglich mit der Übertragung beginnen).

 Trennen der virtuellen Verbindung

Die Datenübertragung erfolgt so lange, bis die eine oder andere Seite entscheidet, die virtuelle Verbindung zu beenden, wenn ein Clear Request Paket übertragen wird. Im Gegensatz zu TCP/IP kann ein Clear-Paket Daten übernehmen, so dass eine Anwendung eine Verbindung erst dann löschen sollte, wenn sichergestellt ist, dass der Remote-Peer alle ausstehenden Datenblöcke empfangen hat - in der Regel ist etwas auf der Ebene des Anwendungsprotokolls notwendig, um dies zu gewährleisten, obwohl die Übertragung eines Datenpakets ohne Länge vielleicht eine Möglichkeit wäre, dasselbe zu erreichen, wenn bekannt ist, dass der Peer die Verbindung beim Empfang von Daten ohne Länge löschen würde.

 Programmierung mit SVCs

Switched Virtual Circuits

Das Schreiben eines Programms zur Handhabung eines X.25 SVC (Switched Virtual Circuit) oder PVC (Permanent Virtual Circuit) über Sockets ist sehr ähnlich dem Schreiben eines Programms zur Verwendung von TCP/IP. Meistens werden genau die gleichen Operationen verwendet, aber mit einigen unterschiedlichen Parametern.

Typischer Server

Ein typischer Server beginnt damit, einen Listening Socket zu erstellen, sich an eine Adresse zu binden und dann auf eingehende Verbindungen zu warten. Dann werden die einzelnen Verbindungen akzeptiert und automatisch ein neuer Socket erstellt, auf dem diese Verbindung abgewickelt wird. Ein Socket-basierter X.25 oder XOT-Server ist genau der gleiche - die Hauptunterschiede zu TCP/IP sind:

  • die Parameter zum Aufruf von socket() beim Erstellen des Sockets - z.B. AF_X25 statt AF_INET für die Adressfamilie
  • das Format der Sockaddr-Struktur, in der die Adresse im Aufruf von bind() angegeben ist.
  • Datentransfer (siehe unten)
  • Verbindungsabschluss (siehe unten)

Typischer Client

Ein typischer Client erstellt einen Socket für die Verbindung und ist dann bereit für die Verbindung. Ein Socket-basierter X.25 oder XOT-Client ist gleich - die Netzunterschiede zu TCP/IP sind gleich:

  • die Parameter zum Aufruf von socket() beim Erstellen des Sockets - z.B. AF_X25 statt AF_INET für die Adressfamilie
  • das Format der Sockaddrestruktur, in dem die Adresse im Aufruf von connect() angegeben ist.
  • Anrufparameter - Anlagen und Anruf-Benutzerdaten, für die es kein TCP/IP-Äquivalent gibt.
  • Datentransfer
  • Verbindungsabschluss

Wenn die Angabe einer lokalen (d.h. anrufenden) Adresse gewünscht wird, muss außerdem eine ioctl() oder Sockets-Option verwendet werden, um die Adresse einzustellen - obwohl dies auch mit bind() möglich ist, wird empfohlen, Sockets nicht zu binden, bevor connect() verwendet wird.

Data Transfer

X.25 oder XOT Datentransfer ist das gleiche wie bei TCP/IP, nur dass TCP-Daten ein einfacher Zeichenstrom sind, während X.25 Paketgrenzen beibehalten werden.

Wenn also 2 Blöcke mit je 2000 Bytes übertragen werden, erhält ein X.25-Empfänger zwei Blöcke mit je 2000 Bytes, während ein TCP-Empfänger die Daten aufgeteilt oder zusammengefügt finden kann.

Es ist mit X.25 möglich, einen Block von Nullbytes zu übertragen, was mit TCP unmöglich wäre (obwohl es möglich ist, leere TCP-Pakete zu übertragen - diese werden für Keep-Alive verwendet). Einige Socket-APIs unterstützen dies jedoch möglicherweise nicht, da das Empfangen von 0 Bytes normalerweise so interpretiert wird, dass die Verbindung geschlossen wurde. Es wird daher empfohlen, die Übertragung von 0-Byte-Blöcken zu vermeiden.

Tatsächlich gibt es nur sehr wenige praktische Anwendungen für die Verwendung von 0-Byte-Blöcken mit X.25 - es gibt keine normale Notwendigkeit für Keep-Alive-Meldungen, da ein Verbindungsabbruch erkannt werden kann, ohne etwas übertragen zu müssen (siehe Verbindungsabbruch).

Aus diesem Grund ist es in der Regel am besten für eine Anwendung, den Empfang eines 0-langen Blocks als Fehler zu behandeln und den Sockel zu schließen (und damit die virtuelle Verbindung zu löschen).

Connection Closure

Mit TCP erhalten Sie normalerweise nur einen Hinweis darauf, dass eine Verbindung abgebrochen wurde (im Gegensatz zu einem absichtlichen Schließen durch den Peer), wenn Sie versuchen, Daten zu senden. Das liegt an der verbindungslosen Natur von IP - es gibt keine Möglichkeit zu wissen, dass eine Verbindung aktiv bleibt, außer durch Senden von Daten. (Es gibt einige Ausnahmen - der Microsoft TCP/IP-Stack in Verbindung mit Dial-Up Networking führt dazu, dass Verbindungen geschlossen werden, wenn eine Dial-Up-Verbindung ausfällt.)

X.25 und XOT hingegen bieten eine sofortige (oder zumindest sofortige, sobald der Fehler erkannt wurde) Benachrichtigung über den Verbindungsabbruch, auch wenn die Verbindung im Leerlauf ist - das liegt daran, dass das X.25-Netzwerkprotokoll verbindungsorientiert ist und jeder Fehler innerhalb des Netzwerks dazu führt, dass alle von der fehlerhaften Verbindung getragenen virtuellen Verbindungen gelöscht werden.

X.25 Permanente virtuelle Schaltungen (PVC)

Die Verwendung eines PVC ist wie die Herstellung einer Kundenverbindung - der Hauptunterschied zu SVCs ist:

  • die Adresse - anstatt eine X.25 DTE-Adresse anzugeben, wird die logische Kanalnummer verwendet. Wenn mehrere X.25-Verbindungen konfiguriert sind, ist es außerdem erforderlich, die X.25-Verbindung auszuwählen
  • es ist notwendig, X.25 Resets zu behandeln - dies geschieht über Erweiterungen der normalen Sockets-API (und die FarSync-API unterscheidet sich unter Windows von Linux).

Am besten ist es, ein PVC beim Anbringen zurückzusetzen - dies kann automatisch von der FarSync X.25 Windows Sockets Schicht durch Angabe einer Socket-Option erfolgen. In diesem Fall wird der connect()-Betrieb erst abgeschlossen, wenn eine Antwort auf den resultierenden Reset-Request empfangen wurde.

Unter Linux müsste jedoch unter den gleichen Umständen ein Reset Request explizit übermittelt werden.

Die Datenübertragung auf einem PVC ist ansonsten ähnlich wie die Datenübertragung auf einem SVC. Eine Anwendung muss in der Lage sein, mit der Situation fertig zu werden, in der die entfernte Anwendung nicht mehr antwortet - in diesem Fall können übertragene Pakete dazu führen, dass sich das Fenster füllt, was zur Blockierung weiterer Sendeaufträge führt. Unter diesen Umständen wäre das Einzige, was getan werden kann, das PVC zurückzusetzen und es erneut zu versuchen, aber natürlich, wenn die entfernte Anwendung immer noch nicht reagiert, wird sich die gleiche Situation wiederholen.

Ein PVC ähnelt in weisser Weise einer Telefon-Hotline, die zu einem einzigen vordefinierten Ziel führt, mit dem Unterschied, dass es keinen Verbindungsaufbau gibt - Daten können sofort gesendet werden, anstatt auf eine Antwort warten zu müssen. Dies bedeutet jedoch, dass der Absender nicht bekannt ist, ob er am anderen Ende der Verbindung steht, wenn Daten übertragen werden.

PVCs mögen auf den ersten Blick einfacher zu handhaben sein als SVCs, da es keinen Verbindungsaufbau und keine Freigabe gibt.

Das Ausarbeiten des Zustands der entfernten DEE ist jedoch nicht so einfach - zum Beispiel kann sie ausgeschaltet werden oder es gibt keine Anwendung, die mit dem PVC verbunden ist. Dies führt daher zu einer Reihe von Komplikationen, so dass nach Ansicht des Autors SVCs anstelle von PVCs verwendet werden sollten, wann immer es eine Wahl gibt.

Allerdings sind PVCs geeignet:

  • wenn ein höherschichtiges Protokoll auf dem PVC verwendet wird, um explizit zu bestimmen, ob die entfernte Anwendung reagiert
  • für die gleiche Art von Anwendungen wie bei UDP.

Beispielsweise sind Marktzufuhranwendungen bei PVCs üblich - einige Netzwerke unterstützen sogar eine PVC-Sendeanlage, so dass Datenpakete, die auf einem PVC übertragen werden, dann vom Netzwerk an eine Reihe von verschiedenen entfernten DEEs gesendet werden.

Die Pakete Call-Setup und Clearing werden bei PVCs nicht verwendet - das PVC beginnt im Datenübertragungszustand. Da das PVC wahrscheinlich schon früher verwendet wurde, sollte bei der Befestigung an einem PVC eine Anwendung dazu führen, dass das PVC zurückgesetzt wird.

Verwendung der FarSync X.25 Sockets API mit PVCs

Mehr über PVCs

 

X.25 und XOT Programmierung über die Sockets API

X.25 Logische Kanäle

Eine X.25-Verbindung ist in mehrere logische Kanäle unterteilt - jeder logische Kanal kann einen separaten virtuellen Schaltkreis tragen.

Jeder logische Kanal wird durch seine Logical Channel Number (LCN) identifiziert, auch bekannt als Logical Channel Identifier (LCI).

Die LCN belegt 12 Bit innerhalb des Headers des X.25-Pakets - es stehen also 4096 verschiedene potenzielle LCNs pro X.25-Verbindung zur Verfügung - 0 bis 4095. In den meisten X.25-Netzwerken ist LCN 0 für den Link-Control-Verkehr reserviert und nicht für virtuelle Schaltungen verfügbar, so dass nur 4095 gleichzeitige virtuelle Schaltungen möglich sind. Einige Netzwerke unterstützen jedoch Virtual Circuits auf LCN 0, so dass 4096 Virtual Circuits unterstützt werden können - dies wird auch von der FarSync X.25 Software unterstützt.

Die logische Kanalnummer ist eine rein lokale Angelegenheit für jede X.25-Verbindung zwischen der DEE und dem Netzwerk - eine virtuelle Verbindung wird in der Regel auf einer völlig anderen LCN auf der lokalen Verbindung zu dem LCN geführt, das auf der entfernten Verbindung zwischen dem entfernten Netzwerkknoten und der DEE auf der anderen Seite des Netzwerks verwendet wird - das Netzwerk stellt sicher, dass die Pakete an das richtige LCN weitergeleitet werden.

Die Anzahl der verfügbaren logischen Kanäle hängt von der vom Netzbetreiber zugewiesenen Anzahl ab - in einem öffentlichen Netz kostet es normalerweise zusätzlich, eine große Anzahl zu haben, und einige Verbindungen können mit nur 2 LCNs versorgt werden.

Auch der Nummernkreis wird vom Netzbetreiber festgelegt - die Konfiguration der Kanalzuordnungen ist für den erfolgreichen Betrieb der X.25-Verbindung von entscheidender Bedeutung: Die Konfiguration der DEE muss mit der Konfiguration der DÜE übereinstimmen.

Dies macht die Konfiguration von X.25 leider schwieriger als TCP/IP - X.25 funktioniert einfach nicht richtig, wenn die Kanalzuordnungen falsch konfiguriert sind.

Aus diesem Grund enthält die FarSync X.25 Software unter Windows ein Dienstprogramm - x25ChanProbe.exe - um die Kanalzuordnungen automatisch zu bestimmen. Dies geschieht durch das Übertragen eines Anrufanforderungspakets auf jedem möglichen LCN und das Überprüfen der Ergebnisse - typischerweise wird eine Anrufanforderung auf einem nicht zugewiesenen Kanal ignoriert, so dass es einige Zeit dauern kann, bis die Ergebnisse gesammelt sind.

Multiplexing

Im Gegensatz zu PSTN ist es mit einem X.25-Netzwerk möglich, mehrere virtuelle Verbindungen gleichzeitig herzustellen - denn X.25-Verbindungen können über eine einzige X.25-Verbindung multiplexiert werden. Multiplexing wird durch die Aufteilung der Verbindung in logische Kanäle erreicht.

Zuverlässigkeit

X.25 ist ein zuverlässiges Protokoll und wurde für den Einsatz in Netzwerken mit signifikanten Fehlerraten bei jeder Verbindung entwickelt. Bei TCP/IP ist die Fehlerbehebung durchgängig (alle erneuten Übertragungen zwischen Client und Server). TCP/IP benötigt daher kein zuverlässiges Verbindungsschichtprotokoll wie LAPB, bei X.25 hat jeder Link Fehlerbehebungsverfahren.

Ein X.25-Netzwerk arbeitet daher besser als TCP/IP, wenn signifikante Fehlerraten auf den Verbindungen auftreten. Der Nachteil ist, dass X.25-Netzwerke die Pakete nicht weiterleiten können, bis sie vollständig empfangen wurden, was zu Verzögerungen bei der Übertragung führt. TCP/IP ist daher bei niedrigen Fehlerraten besser als X.25 - Fehlerraten sind in modernen Netzwerken typischerweise sehr niedrig.

Weitere Informationen zur X.25 Data Link Layer

Datentransfer & Paketbildung

Ein weiterer wesentlicher Unterschied zwischen TCP/IP und X.25 besteht darin, dass die TCP-Datenübertragung strombasiert ist, während die X.25-Datenübertragung paketiert ist. Dies ist ein Konzept, das oft neue Benutzer von TCP abfangen kann - glücklicherweise mit X.25, wenn Sie einen Block von Bytes senden, wird die gleiche Anzahl von Bytes als ein einzelner Block an die Gegenseite geliefert. Im Gegensatz dazu kann der entfernte Peer bei TCP, wenn er beispielsweise 2 Blöcke à 2000 Byte sendet, diesen als einzelnen Block à 4000 Byte empfangen, oder wahrscheinlicher als 3 oder mehr separate Blöcke.

Das heißt nicht, dass die X.25-Daten nicht aufgeteilt werden - viele X.25-Datenpakete können erforderlich sein, um den Block von 2000 Bytes im obigen Beispiel zu tragen. Der Unterschied besteht darin, dass die X.25-Datenpakete durch die Verwendung eines sogenannten "M-bit" miteinander verbunden werden können, so dass der Empfänger sie wieder miteinander verbinden kann.

Viele Anwendungen, die X.25 verwenden, verlassen sich auf die Fähigkeit von X.25, die Grenzen von Datenblocks zu wahren (obwohl es natürlich auch möglich ist, X.25 zu verwenden, um einen einfachen Zeichenstrom zu implementieren).

Um den gleichen Effekt über TCP zu erzielen, ist eine zusätzliche Verkapselungsschicht erforderlich, wie beispielsweise das RBP-Protokoll (Record Boundary Preservation) von Cisco. Es gibt jedoch noch sehr viele andere Möglichkeiten, Datenblöcke über TCP zu kapseln, weshalb die Konvertierung zwischen X.25 und TCP nicht einfach ist, und der Grund für die Existenz des FarSync TCP-X25 Gateways, das eine Reihe von verschiedenen Kapselungen unterstützt, einschließlich Cisco RBP.

IP über X.25 - RFC-1356

Es ist möglich, dass ein X.25-Netzwerk TCP/IP-Daten überträgt. Dies geschieht in der Regel nach den in RFC-1356 definierten Regeln. Dies ist nützlich, wenn ein bestehendes X.25-Netzwerk verwendet wird, um das Backbone eines Teils eines TCP/IP-Netzwerks zu bilden. In diesem Fall wäre das gesamte X.25-Netzwerk selbst als Layer 2 in Bezug auf TCP/IP.

D4 IP over X.25

X.25 over TCP (XOT) - RFC-1613

X.25 virtuelle Verbindungen können über ein TCP/IP-Netzwerk übertragen werden - dies geschieht über das XOT-Protokoll RFC-1613. Dies ist nützlich, wenn ein X.25-Netzwerk ersetzt wurde, aber die X.25-Terminals und -Hosts müssen unverändert weiterarbeiten.

Für XOT ersetzt TCP/IP die X.25 Schicht 2. Es gibt jedoch eine separate TCP-Verbindung pro X.25 Virtual Circuit, so dass es nicht genau dasselbe ist wie das Ausführen von X.25 Layer 3, das direkt über TCP läuft.

D5 XoT

Point-to-Point X.25

X.25 wird nicht nur für die Verbindung mit einem Netzwerk verwendet, sondern kann auch Punkt-zu-Punkt verwendet werden. Punkt-zu-Punkt X.25. Dies wird häufig bei der Verbindung mit einem älteren Host-Computer eingesetzt, und es ist auch nützlich, sich beim Testen eines Terminals oder Hosts auf diese Weise verbinden zu können, wenn kein X.25-Netzwerk vorhanden ist.

Bei der Verwendung von Punkt-zu-Punkt muss ein Ende der Verbindung DTE und das andere eine DCE sein. Um die Sache zu verwirren, ist die DTE/DCE-Konfiguration potenziell unabhängig von jeder der X.25 Schichten; es ist eine gute Idee (wenn Sie die Wahl haben), alle 3 Schichten so zu konfigurieren, dass sie den gleichen Typ haben.

D3 X.25 Point To Point
Der X.25 Guide wurde im Original von FarSite Communications geschrieben, hier angepasst und auf eine Seite zusammengetragen!

© Farsite Communication Ltd.

* Alle Spezifikationen können sich durch den Hersteller initiiert gegebenenfalls ändern!

Daten letztmalig aktualisiert am 20.10.2018

Interessiert an mehr Information? Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Partner | Referenzen
  • Tsystems.gif
  • 1_LOGO_VEEAM.png
  • sbb.gif
  • dekabank.gif
  • Exponet Infrakon 4c.png
  • netcologne.gif
  • ASKLEPIOS.png
  • 1_LOGO_FARSITE.png
  • VOESTALPINE.png
  • AIRBUS.png
  • 1_LOGO_VARONIS.png
  • vodafone.gif
  • deutschepost.gif
  • Postbank.jpg
  • LMK.png
  • NXP.png
  • TDT-AG.JPG
  • 1_LOGO_Avalara.jpg
  • 1_LOGO_SEMATICON.png
  • VENTURETEC.png