Das Modul "compat" stellt ein paar Funktionen zur Verfügung, wie sie aus anderen Unixkernelumgebungen bekannt sind.
"streams" implementiert minimale Streamsunterstützung. Wegen der tty-Verwaltung unter Linux gibt es keinen clone-Treiber (die ist nicht darauf ausgelegt).
Der ISDN-Treiber "isdn_2" ist die Low-Level-Schnittstelle zwischen den ISDN-Karten und dem Steuerprogramm (bin/master). Dieses öffnet /dev/isdnmon, liest eine Konfigdatei (siehe unten) etc. Der Treiber meldet dem Steuerprogramm, welche Karten sich bei ihm angemeldet haben. Es gibt _keine_ Devices für einzelne Karten.
Der Treiber managt das Q.921 -Protokoll für die Karten. Alles andere ist Sache des Steuerprogramms (D-Kanal) bzw. anderer Streams-Module (B-Kanäle).
Ein kommunikationswilliges Programm öffnet einen freien ISDN-Port (/dev/isdn/isdnX, X von 1 bis 99 oder so) und sendet einen Verbindungswunsch an das Steuerprogramm ("atd/subnet/login", öffnen einer Verbindung zum System "subnet" im Protokollmodus "login"). Das Steuerprogramm schiebt diesem Kanal nun automatisch die notwendigen B-Kanal-Module unter (X.75, T.70, V.110, was-auch-immer), baut die Verbindung auf, meldet den Zustand der Verbindung ("RRING", "CONNECT") und verbindet schließlich B-Kanal und Programm. Es erscheint das login:-Prompt des Systems "subnet".
Umgekehrt wird das Steuerprogframm bei einem ankommenden Anruf selbst einen freien Port öffnen und das zuständige Programm auf diesem Port starten. Dasselbe passiert bei abgehenden Anrufen, die auf das zuständige Programm beschränkt sind, zB TCP/IP.
Nimm an, du willst TCP/IP-Pakete verschicken. Du packst also jedes dieser Pakete in einen Datenblock und schickst sie auf die Reise ... halt, so einfach geht das nicht. Normalerweise wird auf dem B-Kanal sowas wie eine gesicherte Verbindung gefahren. (Man kann sich streiten, ob das bei IP-Paketen, die eigentlich sowieso beliebig verlorengehen dürfen, Sinn macht.) Außerdem können manche ISDN-Implementierungen nur ziemlich kleine Pakete verarbeiten; um zu vermeiden, daß die IP-Pakete fragmentiert werden (Overhead: ca. 20 Bytes pro Fragment) oder von der Gegenseite weggeschmissen werden (Overhead: unendlich ;-) , muß man sie so kennzeichnen, daß die Gegenseite sie direkt wieder zusammensetzen kann (Overhead: 2 Bytes; braucht aber besagte gesicherte Verbindung, um vernünftig zu funktionieren). BTX beispielsweise arbeitet so. Außerdem ist ISDN bytesynchrton, d.h. irgendjemand muß kennzeichnen, wo ein Datenpaket aufhört und wo/wann das nächste anfängt. Dafür gibt es, wie üblich, mehrere Methoden...
Streams sind nun eine Möglichkeit, mehrere speziell geschriebene Module auf einem ebenfalls speziell geschriebenen Treiber so zu stapeln, daß jedes Modul eine Einzelaufgabe dieser Arbeit erledigt. Im Idealfall sind die einzelnen Module recht klein und damit debugbar, lassen sich vielseitig zusammenstöpseln, etc.pp. In der Praxis ist die Sache natürlich nicht ganz so einfach; insbesondere ist der Overhead, die Pakete von einem Modul zum nächsten zu schaufeln, nicht zu vernachlässigen. Er ist aber tolerierbar, vor allem wenn man auf die ganzen überflüssigen "Features" (von manchen Menschen als "Bugs" oder "Designfehler" bezeichnet...) verzichtet, die USL und Co. in Sys5 Release 4 dazuerfunden haben.
Die einzelnen Module müssen parametrisiert werden. Im Normalfall spricht man sich mit der Gegenseite vorher ab, ob beispielsweise X.75 verwendet wird und in welchem Modus. Alternativ, und wenn man die Normen auswendig weiß, schaltet man ein Monitor-Modul zuunterst auf den Datenstrom, läßt sich von der Gegenseite anrufen, beobachtet genau was da passiert, und richtet die Konfiguration entsprechend ein. (Das klingt nicht nur kompliziert, das ist es auch. Außerdem gibt es ein paar Details, die sich nicht ohne weiteres beobachten lassen.) Zum Glück haben sich ein paar "normale" Betriebsarten herauskristallisiert, an die sich die meisten Systeme halten.
Im einfachsten Fall werden IP-Pakete direkt auf die Leitung geschickt. Wer zusätzlich noch Appletalk oder IPX oder so machen will, kann diese entweder in IP einpacken (Overhead, kein Kernelsupport unter Linux) oder ein paar Bytes vor die Daten stellen, die angeben, um was für Daten es sich handelt.
Die Bytes können entweder genauso aussehen wie im Ethernet, oder so wie der Pakettyp von PPP. Wer PPP macht, braucht offensichtlich letzteres (PPP selber wird auch bald kommen...); normale Leute nehmen die Ethernet-Codes.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter