Animation und Simulation von Token Ring und FDDI

Die Arbeit gliedert sich im Wesentlichen in zwei Teile: Kapitel 2 behandelt das Token-Ring Protokoll und dessen Umsetzung in eine Simulation. In Kapitel 3 wird dasselbe für das FDDI Protokoll beschrieben. Im letzten Kapitel werden die Ergebnisse und Erfahrungen bei der Programmierung zusammengefaßt und ein Ausblick auf mögliche Weiterführungen der Arbeit gegeben.

Das OSI-Modell (Reference Model of Open Systems Interconnection) wurde von der International Standard Organization (ISO) entwickelt und beschreibt die Protokollschichten eines Kommunikationssystems. Jede Schicht soll bestimmte Leistungen erfüllen, die der nächst höheren zur Verfügung gestellt werden. Ebenso werden die Schnittstellen zwischen den Schichten beschrieben; dazu gehört z.B., daß der Informationsfluß zwischen den einzelnen Schichten möglichst gering sein soll.

Es gibt insgesamt sieben Schichten (s. Abb. 1). Es werden allerdings die Dienste und Protokolle nicht explizit festgelegt, sondern nur, was die einzelnen Schichten bewirken sollen.

In den folgenden Ausführungen werden nur die ersten beiden Schichten betrachtet. Die Bitübertragungsschicht regelt die physikalischen Gegebenheiten der Übermittlung auf der untersten Ebene, während die Sicherungsschicht die Daten in Rahmen verpackt und für deren sichere Übermittlung sorgt. Insbesondere ist die Sicherungsschicht für die Fehlerbehandlung (beschädigte oder verlorene Rahmen) sowie für die Flußkontrolle zuständig.

Die Sicherungsschicht ist in zwei Teilschichten aufgespalten: Die untere wird Medium Access Control (MAC) genannt und regelt den Zugriff auf ein Broadcast Netzwerk. Die IEEE hat dafür mehrere Normen hervorgebracht. Dazu gehören CSMA/CD (802.3), Token-Bus (802.4) und Token-Ring (802.5). Diese Normen beinhalten allerdings auch die Bitübertragungsschicht. Im Folgenden werden nur der Token-Ring und FDDI betrachtet, wobei diese beiden viele Gemeinsamkeiten haben.

Dieses Kapitel beschreibt das Token-Ring Protokoll näher mit allen wichtigen Fehlerkorrekturmechanismen. Im letzten Abschnitt (2.6. Programmierung) wird dann die Umsetzung in ein Simulationsprogramm dargestellt, wobei näher darauf eingegangen wird, welche Elemente des Protokolls implementiert und welche zugunsten einer höheren Anschaulichkeit weggelassen oder vereinfacht wurden.

Ein Token-Ring besteht aus einzelnen Punkt-zu-Punkt-Verbindungen, die zu einem Ring zusammengeschlossen sind. Die Übermittlung erfolgt im Gegensatz zu Token-Bus und CSMA/CD hauptsächlich digital.

Im Token-Ring sind alle Stationen gleichberechtigt beim Kanalzugriff. Dieser wird durch ein Token, ein spezielles Bitmuster, geregelt. Daten werden auf dem Ring in Rahmen verschickt. Es kann nur ein Datenrahmen oder ein Token im Ring sein. Diese Tokenstrategie bezeichnet man deshalb als Single Frame Ring im Gegensatz zum Early Token Release, das hauptsächlich bei FDDI und bei größeren Ringen verwendet wird.

Damit beim Ausfall einer Station nicht das ganze Netzwerk in Mitleidenschaft gezogen wird, gibt es ein sogenanntes Wire-Center (sternförmiger Ring). Dieses kann bei Bedarf eine defekte Station überbrücken und so die Ringstruktur aufrechterhalten.

Bei LANs handelt es sich um Broadcast-Netze, bei denen der Zugriff auf das Übertragungsmedium geregelt werden muß, um ein gleichzeitiges Versenden von Daten zu vermeiden. Da in der Regel nur eine Leitung zur Verfügung steht, muß man eine Zugriffsregelung finden, die keine Station benachteiligt und dabei möglichst noch effizient die Bandbreite des Netzwerkes ausnutzt. Beim Token-Ring wird das durch die oben bereits erwähnte Tokenstrategie erreicht. Im Ruhezustand, wenn keine Station senden will, kreist ständig ein Token im Ring.

Das Bitmuster des Token besteht aus drei Byte. Dabei ist das erste Byte der Startbegrenzer, das mittlere ist für die Zugriffsteuerung und das letzte der Endbegrenzer (Abb. 4). Wenn eine Station senden will, muß sie zuerst das Token erhalten. Dieses wird dann vom Ring genommen und in die ersten zwei Byte für den Datenrahmen umgewandelt, indem ein Bit der Zugriffssteuerung geändert wird. Der Datenrahmen erhält weiterhin noch ein Byte für die Rahmensteuerung (Unterscheidung zwischen Daten- und Steuerrahmen), die Ziel- und Quelladresse, eine Prüfsumme und die eigentlichen Daten, deren Menge nur durch die Token-Haltezeit begrenzt wird. Diese Zeit legt fest, wie lange eine Station ein Token behalten darf. Der Datenrahmen kreist dann wie vorher das Token im Ring und wird von der Station, die in der Zieladresse angegeben ist, gelesen. Genau genommen liest jede Station den Rahmen, aber nur die betroffene Station kopiert ihn auch zur eigenen Verwendung. Nachdem der Datenrahmen dann einmal komplett durch den Ring gegangen ist, wird er von der Sendestation wieder entfernt und dafür ein Token auf den Ring gesetzt. Falls die Auslastung im Netz sehr hoch ist, also alle Stationen etwas zum Senden haben, wird auf diese Weise jede Station nacheinander bedient.

Wenn eine Station sich am Ring anmelden will, werden dabei sechs Phasen durchlaufen, um einen korrekten Ablauf zu gewährleisten:

Im Token-Ring gibt es eine Reihe von Mechanismen, um aufgetretene Fehler zu erkennen und zu beheben. Im folgenden werden diese Fehlermöglichkeiten besprochen. Damit prinzipiell Fehler erkannt werden können, muß eine Station im Ring eine Überwachungsfunktion übernehmen. Diese wird dann Monitor genannt. Die erste Station, die sich im Ring anmeldet, wird automatisch zum Monitor. Falls der Monitor ausfällt, wird nach einem bestimmten Verfahren eine andere Station zum Monitor (s. 2.4.5. Reserve Monitor).

Generell wird beim Auftreten eines Fehlers zuerst der Ring geleert, indem ein spezieller Rahmen (ring purge) an alle Stationen gesendet wird. Danach wird ein neues Token erzeugt.

Im Normalfall wird ein Rahmen von der Sendestation auch wieder vom Ring entfernt und ein neues Token gebildet. Im Fehlerfall kann es passieren, daß ein Rahmen ständig im Ring kreist. Um das festzustellen, setzt die Monitorstation, sobald ein Rahmen bei ihr passiert, ein Bit in der Zugriffskontrolle auf 1. Falls dieses bereits auf 1 gesetzt war, dann ist dieser Rahmen schon mal vorbeigekommen und somit ein Übermittlungsfehler aufgetreten. In diesem Fall wird der Ring geleert und ein neues Token erzeugt.

Wenn keine Station etwas zum Senden hat, dann ist ein normales zirkulierendes Token kein Fehler. Dieser entsteht erst, wenn es sich dabei um ein Token mit erhöhter Priorität handelt (s. 2.5. Prioritätsmechanismus). Die Fehlererkennung und Behebung passieren dann wie bei einem zirkulierenden Rahmen.

Um ein verlorengegangenes Token feststellen zu können, wartet der Monitor eine festgelegte Zeitspanne auf die Bitfolge des Startbegrenzers eines Token oder Datenrahmens. Die Zeitspanne geht davon aus, daß alle Stationen die maximale Tokenhaltezeit ausnutzen. Wenn diese Gesamtzeit überschritten ist, bedeutet dies, daß ein Fehler vorliegt. In diesem Fall wird wie oben beschrieben der Ring geleert und ein neues Token aufgebaut.

Der aktive Monitor sendet ständig einen speziellen Steuerrahmen (Active_monitor_present), um den anderen Stationen mitzuteilen, daß eine Monitorstation im Ring ist. Falls diese selbst einen solchen Rahmen empfängt, der nicht von ihr stammt, dann muß eine andere Station fälschlicherweise die Monitorfunktion übernommen haben. Der Fehler wird einfach behoben, indem die Station auf Standby-Monitor schaltet. Das geschieht auch, wenn die Monitorstation einen Purge-Rahmen empfängt, der eine Initialisierung des Ringes bewirkt.

Jede Station im Ring kann bei Ausfall des aktiven Monitors prinzipiell dessen Funktionen übernehmen, also selbst zum aktiven Monitor werden. Sie sind ständig stand-by. Allerdings ist nicht jede dafür konfiguriert. Um den Ausfall der Monitorstation festzustellen, wartet jede Station eine bestimmte Zeitspanne, die auf jeden Fall länger als die Wartezeit des Monitors ist, auf den Active_monitor_present Rahmen. Wenn dieser nicht vorbeikommt, startet die Station den Token-Claiming-Prozeß (s. nächster Absatz), um selbst Monitor zu werden.

Wie bereits erwähnt wird dieser Prozeß nur bei der Initialisierung oder dem Ausfall des Monitors gestartet. Dabei schickt die Station ein Claim-Token auf den Ring, um anzuzeigen, daß sie Monitor werden will. Jede Station, bei der die entsprechende Option gesetzt ist, nimmt daraufhin an dem Prozeß teil. Sie überprüft, ob die mit dem Claim-Token übermittelte Adresse des Senders höher ist als die eigene. Wenn nicht, nimmt sie das Claim-Token aus dem Ring und schickt ihr eigenes. Wenn dieses noch zweimal bei ihr vorbeikommt, bedeutet das, daß keine andere Station eine höhere Adresse hat. Somit hat diese Station den Prozeß "gewonnen" und schickt nach einer Initialisierung des Ringes ein neues Token.

Der Prioritätsmechanismus im Token-Ring stellt für eine Station eine Möglichkeit dar, bei der Tokenvergabe bevorzugt zu werden. Dazu reserviert sie sich ein Token mit einer höheren Priorität als der aktuellen, indem sie in einem vorbeilaufenden Rahmen die entsprechenden Prioritätsbits setzt. Die Station, die diesen Rahmen ursprünglich geschickt hat, setzt nach der Löschung ihres Rahmens ein Token mit der erhöhten Priorität in den Ring. Dieses Token kann nur von der Station mit der passenden Priorität aufgenommen werden.

Das angestrebte Ziel für die Programmierung des Token-Ring-Protokolls war eine anschauliche Darstellung der auftretenden Vorgänge und Mechanismen. Es sollten der normale Sendevorgang und einige Fehlerfälle in einer Simulationsgrafik dargestellt werden. Durch die Programmiersprache Java konnte schnell eine passende Oberfläche gestaltet werden, die auf allen gängigen Browsern dargestellt werden kann. Um die Übersichtlichkeit zu erhalten, sind allerdings einige Vereinfachungen bei der Umsetzung vorgenommen worden, die aber nicht die Mechanismen selbst verfälschten. Weiterhin gibt es verschiedene Variationen des Token-Ring-Protokolls, die hier nicht berücksichtigt sind. Es gibt z.B. auch hier die Möglichkeit des Early-Token-Release (s. 3. FDDI).

Von der Funktionalität wurden sämtliche Fehlermöglichkeiten implementiert; der Initialisierungsvorgang wurde weggelassen (genauere Ausführungen s. 2.6.3. Programmfunktionen und Einschränkungen).

Da bei der Programmierung Java verwendet wurde, mußte die Problemstellung in ein objektorientiertes Modell übertragen werden. Jedes Token soll durch ein oder mehrere Kreise dargestellt werden. Jeder dieser Kreise, die einzelne Datenpakete darstellen, muß für sich auf dem Ring bewegt und je nach durchzuführender Animation verändert werden. Daher wurde dafür eine eigene Klasse "tokenelement" verwendet. Die Animationsvorgänge und Ausgabe von Statusmeldungen werden von der Klasse "token" gesteuert.

Der Benutzer soll die Möglichkeit haben, die Darstellung möglichst flexibel gestalten zu können. Neben der Möglichkeit, das Darstellungsfenster in der Größe zu ändern, was durch Javas Layoutmanager schon gegeben ist, kann man auch die Anzahl der Stationen im Netzwerk variieren. Alle darstellungsrelevanten Dinge werden dabei von der Klasse "netpaint" geregelt. Hier ist der Aufbau des Fensters, die Funktionen der Buttons und die eigentliche Darstellung des Token-Ring-Netzes implementiert. Schließlich gibt es noch eine Klasse "stations" für die Netzwerkstationen und "speedselect" für die Wahl der Animationsgeschwindigkeit.

Nach dem Starten des Programms wird standardmäßig ein Token-Ring mit zwei Stationen dargestellt. Mit dem "Add" bzw. "Remove"-Button kann man die Anzahl jedoch zwischen 2 und 15 erhöhen bzw. erniedrigen. Die rote Station stellt den Monitor dar. Mit dem "Start"-Button wird dann die Animation gestartet, d.h. das Token - dargestellt als roter Kreis - beginnt zu zirkulieren. Dabei wird der Initialisierungsvorgang (s. 2.3. Initialisierung) nicht mehr dargestellt. Als Default-Einstellung kann man nun mit der Maus abwechselnd Sende- und Empfangsstationen wählen, die durch ein Rechteck bzw. Kreis gleicher Farbe gekennzeichnet werden.

Sobald das Token an einer Sendestation vorbeikommt, wird der Sendevorgang ausgelöst, was man an den Datenrahmen - dargestellt als blaue Kreise -, die die Station verlassen, erkennen kann (s. Abb. 8: Sende- und Empfangsvorgang im Token-Ring). Wegen der Übersichtlichkeit wird der Sendevorgang nach 50 Datenrahmen automatisch beendet. Man kann aber den Vorgang mit dem "Send Stop"-Button schon vorher abbrechen. Wenn die Datenrahmen an der Empfängerstation vorbeikommen, werden sie als unausgefüllte blaue Kreise dargestellt. Zusätzlich zu der graphischen Visualisierung wird ständig der Status des Monitors und die Access Control Bits angezeigt.

Neben dem normalen Sendevorgang können alle in Kapitel 2.3. beschriebenen Fehlerfälle dargestellt werden. Im Fehlerfall des "Zirkulierenden Rahmens" wird davon ausgegangen, daß die Sendestation nicht in der Lage war die Datenrahmen wieder vom Ring zu nehmen. Die Kennzeichnung der Sende- und Empfangsstation wird zwar wieder entfernt, die Datenkreise laufen allerdings weiter. Da bei dem vorhergehenden Sendevorgang das Prüf-Bit gesetzt wurde, erkennt die Monitorstation den Fehler und löscht ihrerseits die Datenrahmen. Danach wird wieder ein Token freigegeben. Bei einem verlorenen Token wird sofort der Kreis gelöscht und die Monitorstation beginnt eine gewisse Zeitspanne abzuzählen. Diese ist die in Kapitel 2.3.3 erwähnte Zeit, die sich aus der Summe der maximalen Tokenhaltezeiten für alle Station errechnet. Danach erzeugt die Monitorstation ein neues Token. Während die eben erwähnten Fehlerfälle direkt aus der Auswahlliste gewählt werden können, gibt es noch weitere Fehlerzustände, die sich durch An- bzw. Abschalten einer Station oder Monitors ergeben. Dazu gehören die Fehlerfälle "mehrere aktive Monitore" und "Ausfall des Monitors". Die Möglichkeit des "Zirkulierenden Tokens" wurde nicht implementiert, da die Darstellung des Prioritätsmechanismusses schlecht zu visualisieren ist. Bei der Programmierung wurde auch berücksichtigt, daß mehrere Fehlerfälle gleichzeitig auftreten können. Dabei muß man zwei Fälle unterscheiden. Zum einen gibt es nicht-zeitkritische Fehler, beispielsweise beim Ausfall der Sendestation. Diese Fehler werden nach der Reihenfolge in der sie bekannt werden, d.h. das Token bzw. die Datenrahmen in einer Station eintreffen, bearbeitet und auch so dargestellt. Zeitabhängige Fehler wie z.B. beim verlorenen Token, bei dem der Reservemonitor eine gewisse Zeitspanne wartet, um ein neues Token zu generieren, wurden nicht eins zu eins umgesetzt. Sobald der Fehler "verlorenes Token" gewählt wird, läuft eine Zeituhr ab (dargestellt im Monitorstatus Fenster), wobei jede Millisekunde ungefähr einer Sekunde entspricht.

Eine weitere Vereinfachung bei der Darstellung ist die Menge der Datenpakete im Ring. Im Realfall werden mehr Daten anfallen, als der Ring aufnehmen kann. Dabei sendet die Station Datenpakete, während sie gleichzeitig ihre Daten, die den Ring schon umlaufen haben, wieder entfernt. An dem dargestellten Sendemechanismus würde sich aber nichts ändern.

In diesem Kapitel wird das FDDI-Protokoll und dessen Umsetzung in eine Simulation behandelt. Der Schwerpunkt liegt diesmal allerdings nicht auf Fehlerkorrekturmechanismen, sonder bei der Darstellung des wesentlich kompexeren Sendevorganges.

FDDI (Fibre Distributed Data Interface) läßt sich im OSI-Modell bei den ersten beiden Schichten einordnen (s. Abb. 9: Einordnung von FDDI im OSI-Modell).

Bei FDDI handelt es sich wie auch beim Token-Ring um eine Ringstruktur. Im Gegensatz zum Token-Ring werden hier allerdings zwei Ringe verwendet, ein Primär- und ein Sekundärring. Sie bieten eine erhöhte Ausfallsicherheit. Ein Ring ist dabei nur in Bereitschaft, um im Fehlerfall einzuspringen. Wie beim Token-Ring dient jede Station im Ring als Verstärker für durchgehende Nachrichten. Es gibt auch einen Token-Mechanismus um den Netzzugriff zu regeln. Anders als beim Token-Ring wird bei FDDI aber nach der Übertragung der Datenrahmen sofort wieder ein Token auf den Ring gesetzt. Somit können sich also mehrere Datenrahmen von unterschiedlichen Stationen im Ring befinden (= Early Token Release). Bei FDDI ist das im Praktischen auch eher denkbar als bei Token-Ring, der eine kleinere Maximallänge und somit geringere Kapazität besitzt.

In dem Timed Token Protokoll werden verschiedene Zugriffsbedingungen geregelt. Beispielsweise soll eine mittlere Tokenumlaufzeit garantiert werden. Sie liegt etwa zwischen 4 ms und 165 ms (s. Abb. 10: Zeittafel verschiedener Ereignisse in einem Ring). Um ein solche Garantie geben zu können, werden bei FDDI Timer verwendet, nämlich TTRT (Target Token Rotation Time), TRT (Token Rotation Time) und THT (Token Holding Time). Die TTRT wird am Anfang von den Stationen ausgehandelt, indem die Zeit gemessen wird, die ein Token beim Durchlaufen des ganzen Ringes benötigt. Die im Ring vereinbarte Umlaufzeit ist dann ungefähr das Doppelte der TTRT. Im einzelnen funktioniert der Tokenmechanismus bei FDDI folgendermaßen: Zu Beginn wird der TRT-Zähler für das Token auf den Wert der TTRT gesetzt und dann - während das Token den Ring umläuft - dekrementiert. Wenn das Token dann wieder eintrifft, wird geprüft, ob der TRT-Zähler bereits abgelaufen ist. In diesem Fall wird das Token als "Late Token" gekennzeichnet. Ein solches Token darf dann nur noch für synchrone Übermittlung (s. 3.8. Synchrones FDDI) genutzt werden. Im anderen Fall wird die verbleibende Restzeit in den THT-Zähler kopiert, der dann angibt, wie lange das Token in der Station gehalten werden darf. Das bedeutet dann also, je später das Token eintrifft, desto kürzer darf es nur gehalten werden. Dadurch wird erreicht, daß das Token innerhalb einer garantierten Zeit den Ring umläuft. Diese darf maximal das Doppelte der TTRT betragen. Wenn diese Zeit abgelaufen ist, liegt ein Fehler vor.

Bedeutung	Zeit [ms]
maximale Ringumlaufzeit Datenpaket	1,617
maximale Signallaufzeit durch alle PMD & PHY	0,45
Set-Up-Zeit des Senders	0,0035
Dauer eines Tokens	0,00088
Sendedauer Frame 9000 Symbole	0,361
minimaler Sicherheitsabstand	0,3645
minimale Zeit eines Tokenumlaufs	2,52
maximale Zeit eines Tokenumlaufs	165

Weiterhin werden sogenannte Service-Klassen definiert. Im Normalfall wird die asynchrone Service-Klasse verwendet. Dabei wird jeder Station eine wahrscheinliche Sendedauer zugestanden, die aber nicht garantiert ist. Ebenso ist jede gleichberechtigt. Die synchrone Serviceklasse gibt dagegen einer Station eine garantierte Zeitspanne zum Senden. Das ist bei multimedialen Applikationen wie Bild- und Tonübertragungen sinnvoll. Eine solche Station hat Vorrang vor einer asynchronen. Sie beansprucht also eine höhere Bandbreite vor allen anderen.

Restricted Token gibt es nur bei der asynchronen Übertragung. Der Normalzustand ist allerdings ein Nonrestricted Token. Hierbei kann eine Station einen Token priorisieren, ähnlich dem Prioritätsmechanismus im Token-Ring. Bei FDDI gibt es dazu 7 Prioritätsstufen. Mit einem Restricted Token dagegen hat jede Station die gleiche Bandbreite und kann keinen Prioritätstoken erzeugen. Dafür sind an der Kommunikation mit einem Restricted Token nur wenige Stationen beteiligt. Die Station, die diesen Prozeß starten will, muß dazu auf ein Nonrestricted Token warten. Dieses nimmt sie dann vom Ring und schickt einen oder mehrere Datenrahmen an den/die Empfänger. Die Datenrahmen veranlassen außerdem den Empfänger, in den Restricted Mode zu gehen. Die sendende Station schickt nach den Datenrahmen gleich ein Restricted Token hinterher. Damit werden die übrigen Stationen am Senden gehindert. Die Empfangsstation geht dann nach dem Erhalt der Datenpakete ebenfalls in den Restricted Mode. Somit ist jetzt ein Datenaustausch nur zwischen diesen speziellen Stationen über den Restricted Token möglich. Auch kann es nur einen Restricted Token Dialog geben. Um diesen Dialog zu beenden, schickt eine Station mit den letzten Datenpaketen eine entsprechende Aufforderung an den oder die Empfänger.

Im FDDI gibt es Token- und Datenrahmen. Die Datenrahmen kann man weiterhin in folgende Gruppen einteilen:

SMT steht für Station Management, während LLC Logical Link Control bedeutet. Dies betrifft aber bereits die nächste Teilschicht innerhalb der Sicherungsschicht, ist also der MAC-Teilschicht übergeordnet.

Im Frame-Control-Feld wird u.a. festgelegt, ob es sich um einen Restricted oder Nonrestricted Token handelt, oder ob der Rahmen zur synchronen oder asynchronen Übertragung gehört.

Die Frame Check Sequence wird zur Erkennung von Übertragungsfehlern verwendet. Interessant bei der Fehlererkennung ist noch das Frame Status Feld. Hier gibt es drei Felder. Das erste ist der Error Detect Indicator. Wenn dieser von einer Station gesetzt wird, wissen alle folgenden Stationen, daß der Rahmen bereits als fehlerhaft erkannt wurde. Das nächste Feld "Address Recognized Indicator" wird von der Zielstation gesetzt. Somit kann die Sendestation erkennen, ob ihr Rahmen auch angekommen ist. Das letzte Feld schließlich markiert, ob der Rahmen erfolgreich in der Zielstation kopiert werden konnte.

MAC-Frames werden ausschließlich bei der synchronen Übertragung verwendet. Sie können sowohl zur Steuerung als auch zur Fehlerbehebung verwendet werden. Es gibt zwei Arten: Beacon- und Claim-Frames. Während die Claim-Frames zum Aushandeln der TTRT (s. 3.2. Timed Token Protokoll und 3.6. Initialisierung des FDDI-Ringes) verwendet werden, dienen die Beacon-Frames zur Fehlererkennung. Dazu werden deren Info-Felder verwendet. Z.B. werden darin Auskünfte über den Status des Empfängers gespeichert.

Der Beacon-Prozeß kann neben der Initialisierung noch bei folgenden Fällen ausgelöst werden:

Bei dem Beacon-Prozeß ist es das Ziel, alle Stationen einzubeziehen, um somit eine Fehlerdiagnose oder Ring-Restauration zu unterstützen. Sobald irgendeine Station mit dem Beacon-Prozeß beginnt, sendet sie ununterbrochen Beacon-Frames. Die nachfolgende Station wird dadurch gezwungen in der Repeat-Modus zu gehen, also die Beacon-Frames weiterzuschicken. Es ist ihr dabei nicht möglich, irgendwelche Daten-Frames zu schicken. Falls die Station selbst Beacon-Frames erhält, geht sie ebenfalls in den Repeat-Modus. Wenn diese allerdings von ihr selbst stammen, dann beendet sie den Beacon-Prozeß und geht in den Claim-Prozeß über.

Der Claim-Prozeß findet normalerweise nach dem Beacon-Prozeß statt. Allerdings kann er auch im Fehlerfall, wenn z.B. die maximale Umlaufzeit (Valid-Transmission-Timer) abgelaufen ist, aufgerufen werden. Im Claim-Prozeß wird jetzt die Umlaufzeit des Token (TTRT) ermittelt. Dazu macht jede Station "Vorschläge", die mit dem Claim-Token mitgeschickt werden. Genommen wird dann diejenige mit der kürzesten Zeit. Wenn das mehrere Stationen sind, werden noch andere Kriterien hinzugezogen. Diese Station beendet daraufhin den Claim-Prozeß und schickt ein Nonrestricted-Token auf den Ring. Falls der Claim-Token gar nicht mehr zurück kommt, wird wieder der Beacon-Prozeß gestartet, um den Fehler zu ermitteln.

Der gravierendste Fehler in einem Netz ist der Ringbruch. Während beim Token-Ring zur Überbrückung das Wire-Center verwendet werden kann, wird bei FDDI der Sekundärring verwendet. Über diesen kann ein Ring aufgebaut werden, der aus Primär- und Sekundärleitung der verbleibenden Stationen besteht (s. Abb. 14: Neubildung des Ringes bei einem Ringbruch [2]).

Das synchrone FDDI ist im MAC berücksichtigt, d.h. die Timer und Abläufe zur Steuerung in der FDDI-Ebene. Allerdings gibt es keine Steuerungsmechanismen für die Zuteilung der synchronen Bandbreite. Diese wurden nachträglichen bei einem Zusammenschluß mehrerer Firmen im "Synchronus Forum" festgelegt. Danach übernimmt die Zuteilung der Bandbreite eine zentrale Station (SBA: Synchronus Bandwidth Allocator). Es ist sogar möglich synchronen und asynchronen Betrieb gleichzeitig zu nutzen.

Wie schon beim Token-Ring sollten auch hier die Vorgänge des FDDI-Ringes in einer graphischen Simulation anschaulich dargestellt werden. Besonderen Vorzug hatte hier die Darstellung des Sendemechanismusses. Als einziger Fehlerfall wurde der Ringbruch implementiert.

Aufgrund der strukturellen Ähnlichkeit zum Token-Ring wurden bei der Programmierung dieselben Klassen verwendet. Lediglich die Klasse "tokenelement" erhält eine neue Bedeutung, da jetzt aufgrund des Early Token Release mehrere Datenrahmen und Token gleichzeitig verwaltet werden müssen. Es gibt somit eine 1:n Beziehung zwischen "token" und "tokenelement".

Die Vorbereitungen zum Starten einer Simulation sind hier analog zum Token-Ring. Zuerst werden nur zwei Stationen dargestellt. Nachdem man die gewünschte Anzahl der Stationen gewählt hat, kann man mit dem "Start"-Button die Animation starten. Das Token beginnt dann generell bei der Station 0 zu kreisen, da der Initialisierungsvorgang hier nicht dargestellt wird. Am unteren Bildschirmrand gibt es jetzt nur noch ein großes Statusfenster, in dem sämtliche Aktionen mitprotokolliert werden. Auf der linken Seite befindet sich die Auswahlliste, mit der man für die Selektion zwischen "Senden", "An-/Ausschalten der Station" und "Ringbruch" wählen kann (s. Abb. 16: Sende- und Empfangsvorgang bei einem Ringbruch). Die Sende- und Empfangsstationen werden hier gleichfalls mit einem Rechteck bzw. Kreis dargestellt. Ein Sendevorgang besteht hier generell nur aus 5 Datenkreisen. Danach wird gleich das Token freigegeben (Early Token Release). Somit entfällt der "Send Stop"-Button. Die Datenrahmen erhalten dabei dieselbe Farbe wie die Markierung der Sendestation, um bei vielen gleichzeitigen Sendevorgängen die Übersicht zu behalten.

Eine Sendestation kann nicht abgeschaltet werden, da der dazu gehörende Fehlermechanismus nicht implementiert ist. Wenn die Empfangsstation abgeschaltet wird, dann werden die Datenrahmen nicht vom Ring entfernt und kreisen solange bis die Station wieder angeschaltet wird.

Bei Auswahl des "Ringbruchs" muß man zwischen zwei Stationen klicken, um die Stelle des Bruches zu markieren. Die Auswahl ist nur möglich, wenn gerade keine Station am Senden ist. Durch nochmaliges Klicken auf dieselbe Stelle kann der Bruch wieder entfernt werden. Wird der Bruch an einer Stelle gewählt, an der sich auch gerade das Token befindet, dann läuft das Token normal weiter bis es das nächste Mal die Bruchstelle erreicht. An der Bruchstelle werden dann das Token und alle Datenpakete auf den zweiten Ring umgeleitet. Dort laufen sie dann gegen den Uhrzeigersinn weiter. Der zweite Ring kann - wie der erste auch - Datenpakete an die Stationen schicken und empfangen. Wird die andere Seite der Bruchstelle erreicht, dann gelangen die Daten wieder auf den ersten Ring.

Um bei vielen Sende- und Empfangsvorgängen die Übersicht zu behalten, wurden bei dem FDDI-Applet die Datenkreise in derselben Farbe wie die Markierung der Sende- und Empfangsstation dargestellt. Somit kann man sie jederzeit den entsprechenden Stationen zuordnen.

Die Programmierung einer Simulation in Java schien anfangs durch die bereits eingebauten Layoutfunktionen von Java recht problemlos. Leider traten im Verlauf der Programmierung immer wieder Fälle auf, an denen sich das verwendete JDK (Version 1.0.2) als noch nicht ganz ausgereift präsentierte. Diese zeigen sich auf verschiedenen Plattformen (getestet wurde Windows 95, Windows NT 4.0 und Linux in Zusammenhang mit Netscape 3.02 und Communicator 4.05) mit unterschiedlichen Auswirkungen.

Aufgrund der Thread-Mechanismen in Java ist eine Repaint-Methode, die auch während einer komplexen Animation läuft, nur mit erheblichem Aufwand zu realisieren. Das liegt u.a. daran, daß sich in Java nicht direkt ermitteln läßt, ob ein Fenster verdeckt wird. Erst wenn der Fensterinhalt wieder erscheint, wird ein Repaint ausgelöst. Deswegen sollte man das Applet-Fenster nicht mit anderen Anwendungsfenstern überdecken, während die Animation läuft, um nicht einen Repaint-Aufruf zu erzwingen.

Auch ohne explizite Verwendung von Threads werden in Java intern solche verwendet. Bei einer nur 1 Sekunde dauernden grafischen Ausgabe kann es passieren, daß nachfolgende Anweisungen ausgeführt werden, bevor die Ausgabe abgeschlossen ist. Auch im Zusammenspiel mit den Sicherheitsfunktionen bei Netscape ist das Erzeugen von Threads problematisch.

Ein gravierender Punkt bei Java ist weiterhin die Geschwindigkeit. Gerade für eine Simulation stellt das einen entscheidenden Faktor dar. Das langsamste System, mit dem die Applets getestet wurden, war ein 486/133MHz. Von der Geschwindigkeit hängt es auch ab, ob die Repaint-Methode korrekt funktioniert; ansonsten kommt es zu der oben beschriebenen "Überholung" eines Threads bei der Grafikausgabe.

Die in der Zwischenzeit erschienenen Erweiterungen für Java wie z.B. JavaBeans und Swing konnten noch nicht verwendet werden, da die gängigen Browser diese nicht so ohne weiteres unterstützen. Mit der Zeit werden aber die Browserhersteller dies nachholen, so daß man auf eine erweiterte Funktionalität bei der grafischen Ausgabe und eine weniger problematische Thread-Funktionalität hoffen kann. Damit könnte man die Animation noch aufwendiger gestalten, z.B. die Einbindung der Initialisierungsvorgänge oder der Fehlerkorrektur bei FDDI.