O
A
B
C
D
E

2. Termin 1: SDT und Send-and-Wait

Für die Vorbereitung ist das Lesen des Skriptes ausreichend.

Es ist jedoch empfehlenswert auch die Folien der Vorlesung des Teils „Introduction to SDL“ der Unit 15 und der Unit 8 (ARQ-Approach) zu lesen. Die Folien der Unit 15 dienen als Grundlage für das Verständnis des sehr empfehlenswerten Tutoriums des SDL-Forums (Die Kapitel 2 und 3 des Tutoriums sind für das Praktikum relevant). Wer lieber audiovisuelle Medien bevorzugt, dem sei das Youtube Video "Introduction to SDL" empfohlen.

Des weiteren sollten Sie sich mit dem SDL System des „Send-and-Wait"-Protokolls vertraut machen.

SDL System des „Send-and-Wait"-Protokolls

Zusätzliches

Weitere Informationen zur Handhabung des verwendeten SDL Design Tools SDT sind in den beiden folgenden Dokumenten zu finden:

„SDT/SDL Intoduction"
„SDL Data Types"
„SDL/TTCN Suite User Manual"

Im Block C wird ein erster Einblick in die Benutzung von SDT vermittelt. Neben der Bedienung der Benutzeroberfläche wird geübt, wie man ein modelliertes System simulieren und beobachten kann. Des weiteren soll untersucht werden, wie ein in SDL spezifiziertes Kommunikationssystem, das für den Datentransport das “Sendand- Wait”-Protokoll benutzt, sich bei sicherer und bei unsichererÜbertragung verhält.

2.1 Funktionsweise des "Send-and-Wait"-Protokolls

Das Protokoll „Send-and-Wait”-Protokoll (SnW-Protokoll) ist wahrscheinlich eines der einfachsten Verfahren, mit dem zwei Prozesse - unter bestimmten Voraussetzungen an den Übertragungskanal - relativ sicher miteinander kommunizieren können. Dieses Protokoll ist dabei prinzipiell an keine bestimmte Schicht des OSI-Referenzmodells gebunden.

Die folgende Beschreibung dieses Protokolls soll als Grundlage bzw. Referenz für die Bearbeitung der Aufgaben des ersten Termins dienen, wobei an dieser Stelle darauf hingewiesen wird, dass bei Tanenbaum und Halsall geringfügige Unterschiede existieren.

Wie bereits in Kapitel 1.3.1 erwähnt wurde, wird auf die Darstellung und Untersuchung des Verbindungsauf- und -abbaus zwischen Sender und Empfänger verzichtet, da sich die Aufmerksamkeit auf die grundlegenden Protokollmechanismen für den Nutzdatentransport konzentrieren soll.

Im Folgenden wird nun kurz in Stichworten der Ablauf des Protokolls für eine unidirektionale (Nutz-)Datenkommunikation skizziert. Das „Send-and-Wait“-Protokoll verwendet dabei keine Sequenznummern zur Unterscheidung der einzelnen Datenpakete.

Die folgenden Verständnisfragen sollten bereits zur Bearbeitung der Hausaufgabe beantwortet werden können und sollten Teil des Protokolls für diesen Block sein.

  • Welche der Fehlerarten duplicate, lose, reorder werden im medium vom “Send-and-Wait”-Protokoll nicht erkannt?
  • Bei welchen dieser Fehlerarten kommt es dann zu Fehlern im von der destination empfangenen Datenstrom und wie äußert sich das?
  • Welche der 6 Fehlerarten im medium sind aus Sicht des Empfängers bzw. des Senders nicht zu unterscheiden? Unterschiedliche Zeitabstände zwischen den eintreffenden Paketen sollen hierbei vernachlässigt werden.
  • Enthält das “Send-and-Wait”-Protokoll Mechanismen zur Flusssteuerung? Die Antwort ist zu erläutern.

2.2 Durchführung

2.2.1 Die Benutzeroberfläche von SDT

Zunächst soll die Benutzeroberfläche von SDT kennengelernt werden. Eine hierzu notwendige Vorstellung vom Grundkonzept des SDL-ToolSets SDT und ein erster Überblick über die einzelnen ”User Interfaces“ (UIs) sind in der SDT-Dokumentation erhalten. Anschließend wird der Umgang mit den UIs im Organizer und im SDL-Editor geübt.

Der Organizer (siehe Abb. 3) ist das zentrale Element des gesamten ToolSets. Hier wird die Struktur eines Kommunikationssystems mit den zugehörigen Dateien verwaltet, werden Konfigurationen verändert und die verschiedenen Tools gestartet (z.B. SDL-Editor, Analyzer, Simulator, Validator). Wenn zum Beispiel ein SDL-Diagramm aus der im Organizer-Fenster dargestellten Systemstruktur per Doppelklick geöffnet wird, dann wird automatisch der SDL-Editor gestartet. Dieser besitzt wiederum in seiner Symbolleiste zwei für die Navigation in der Systemstruktur wichtige Symbole: Reference Page und Organizer. Das erste Symbol holt das, dem aktuellen Diagramm in der Systemstruktur direkt übergeordnete Diagramm ins Editor-Fenster, das zweite Symbol macht den Organizer sichtbar (auch wenn er unter vielen Fenstern verborgen ist). Mittels Doppelklick auf die Referenzsymbole in den SDL-Diagrammen kann man sich in der Systemstruktur abwärts bewegen.


Abb. 3: Organizer Fenster eines Systems

Übung 1: Erstes Kennenlernen von SDT (10 min)

Zunächst soll SDT gestartet werden (dies geschieht durch Eingabe des Befehls: sdt in der Shell), anschließend soll das SnW-System geöffnet und erkundet werden, sowie seine Struktur und seine internen Kommunikationswege mit Hilfe des Organizers (siehe Abb. 3) und des Editors nach eigenem Ermessen kennengelernt werden. Das Öffnen des SnW-Systems erfolgt im Organizer durch Anklicken des „Open“-Buttons in der Symbolleiste und durch anschließende Auswahl der Systemdatei mit der Endung .sdt im Verzeichnis BlockC/T1_SnWProtokoll/.

Anschließend öffnen Sie durch einen Doppelklick den receiver_process im SDL-Editor. Notieren Sie sich die möglichen Ereignisse und die Namen der Zustände, den der Prozess annehmen kann. Schließen Sie anschließend wieder den Editor.

In einem nächsten Schritt öffnen Sie die Prozesse im Medium und bestimmen die Verzögerungszeit des Mediums und die Zeit zwischen zwei Fehlern.

2.3 Der Simulator von SDT

Nachdem die Struktur des SnW-Systems bekannt ist, soll nun sein Verhalten betrachtet werden. Für die Untersuchung des Verhaltens eines modellierten Systems gibt es in SDT viele verschiedene Möglichkeiten. Im Rahmen dieses Laborpraktikums werden nicht alle davon verwendet.

Die gebräuchlichsten Funktionen zur Untersuchung des Verhaltens eines Systems stellt der Simulator zur Verfügung. Er bietet neben einem kontrollierbaren Ablauf des Systems (Step-by-Step oder bis zu einem Abbruchkriterium) vielfältige Beobachtungs- und Manipulationsmöglichkeiten. So lässt sich zum Beispiel mit Hilfe des so genannten MSC-Trace die Interprozesskommunikation (d.h. das Versenden und Empfangen von Signalen) in beliebigen Bereichen des Systems beobachten und aufzeichnen. Des Weiteren können mit Hilfe des Simulators Variablen, Timer, States und Input-Queues beobachtet und manipuliert werden.


Abb. 4: Simulator UI

Das User Interface des Simulators (siehe Abb. 4) wird mit dem Simulate-Button in der Symbolleiste des Organizers gestartet. Weil dabei die Simulator-Datei neu generiert wird, ist unbedingt darauf zu achten, dass im Organizer-Fenster die Wurzel (root) der Systemstruktur, also das System-Diagramm, markiert ist (einfacher Mausklick) - die generierte Simulator-Datei enthält sonst nicht das komplette System.

2.3.1 Initialisieren des Simulators

Nach dem Start des Simulators werden die einzelnen Prozesse geladen aber noch nicht gestartet („Start-State“). Erst wenn der Simulator in Gang gesetzt wird, dann wird für alle Prozesse die so genannte “Start-Transition“ durchgeführt, also der Übergang vom Start in den ersten Zustand des Prozesses. Bei diesem Vorgang werden auch die zum Prozess gehörenden Variablen initialisiert, d.h. auf den spezifizierten Anfangswert gesetzt. Ist kein Anfangswert explizit angegeben, dann wird die Variable mit „0“ bzw. „False“ initialisiert. Da die Variablen also erst bei der Start-Transition ihren Anfangswert erhalten, hat es keinen Sinn, sofort nach dem Start oder Restart des Simulators (Befehl Restart im Menü File) irgendwelche Variablenwerte zu ändern - diese Werte werden bei der Initialisierung wieder überschrieben. Um eine Variable in einem bestimmten Prozess zu ändern, muss erst der „Scope“ auf diesen Prozess gesetzt werden (Befehl „Set Scope“ im Menü „Examine“). Damit wird der Prozess ausgewählt, in dem die gesuchte Variable enthalten ist. Einzelne Transitionen können mit dem Button Transition im Modul Execute ausgeführt werden. Einen Überblick über die noch anstehenden (Start-)Transitionen wird durch dem Befehl „Ready Q“ im Menü „Examine“ gegeben.

Übung 2: Initialisieren des Simulators (10 min):

  • Simulator starten
  • „Ready Q“ anschauen
  • eine Variable mit Initialwert, der verschieden von Null ist, beobachten (z.B. Variable d in der source);
  • (Start-)Transitionen durchführen
  • „Ready Q“ anschauen
  • Variable beobachten
  • Simulator Restart
  • Variable vor den Start-Transitionen auf einen Wert verschieden vom Initialwert ändern
  • (Start-) Transitionen durchführen
  • „Ready Q“ anschauen
  • Variable beobachten.

2.3.2 Beobachten des Systemverhaltens

Als nächstes wird eine Möglichkeit vorgestellt, wie man relativ einfach das Verhalten des gesamten Systems oder von Teilbereichen beobachten kann. Mit dem Befehl „MSC Trace:Start“ im Menü Trace wird ein „interaktives MSC-Log“ gestartet (siehe Abb. 5), auch MSC-Trace genannt. Auf diese Weise werden alle beobachtbaren Signalisierungen in Form eines MSCs protokolliert. Interaktiv ist dieses MSC-Log, weil man zu jeder Zeit das MSC editieren kann und die Auswirkungen von Änderungen, die der Benutzer am simulierten System zur Laufzeit vornimmt, sofort beobachtbar sind. Die „online“- Editiermöglichkeit ist hier sehr nützlich, da die im MSC-Editor dargestellten Prozesse nach dem Start des MSC-Logs oft erst in eine übersichtlichere Reihenfolge gebracht werden müssen (einfach mit der Maus ziehen, wobei man sich am Seitenbeginn befinden muss). Welche Instanzen (Prozesse und Blöcke) überhaupt beobachtet werden, lässt sich mit dem Befehl „MSC Level:Set“ im Menü Trace für jede Instanz festlegen. Wird für eine Instanz kein expliziter TraceLevel-Wert angegeben, dann orientiert sich der Simulator am TraceLevel-Wert der Instanz, die diese Instanz referenziert, d.h. in der Systemstruktur direkt übergeordnet ist. Bei einem Level-Wert von „0“ wird die jeweilige Instanz nicht beobachtet, d.h. sie taucht im MSC gar nicht erst auf, was erheblich zur Übersichtlichkeit beitragen kann. Da die Transitionen der gerade nicht beobachteten Instanzen aber natürlich trotzdem ausgeführt werden, kommt es dann nicht bei jedem Betätigen des Transition-Buttons zu einem Fortschreiben des MSC-Logs.


Abb. 5: Der MSC-Editor

Übung 3: Einschalten der MSC Aufzeichnung (10 min)

2.3.3 Breakpoints

Wenn im Menü „Execute" des Simulator UIs auf den Button Go geklickt wird, dann fängt die Simulation des Systems an zu laufen, d.h. alle jeweils anstehenden Transitionen werden automatisch ausgeführt. Anhalten kann man die Simulation auf zwei verschiedene Arten: per Hand (Button Break) oderautomatisch bei Erfüllung einer vorher festgelegten Abbruchbedingung, dem sogenannten “Breakpoint”. Es gibt verschiedene Arten von Breakpoints:

  • Output-Breakpoint: Der “Output-Breakpoint” wird beim Versenden eines festgelegten Signals ausgelöst (Befehl „Output“ im Menü „Breakpoint“). Angegeben werden muss der Name des Signals, das beim Versenden die Simulation unterbrechen soll, der Prozess, der dieses Signal sendet und der Prozess, der das Signal empfängt. Zusätzlich kann für den sendenden und empfangenen Prozess eine bestimmte Inkarnation angegeben werden. Nur wenn diese Instanz das Signal versendet, wird dieSimulation angehalten. Man kann hier auch festlegen, dass der Breakpoint erst beim n-ten Auftritt dieses Signals ausgelöst wird.
  • Variable-Breakpoint: Der „Variable-Breakpoint” wird ausgelöst, wenn sich der Wert der angegebenen Variable ändert (Befehl „Variable´“ im Menü „Breakpoint“). Beim Einrichten des Breakpoints bietet der Simulator eine Liste zu beobachtender Variablen an. Per Mausklick wird nun die gewünschte Variable ausgewählt. Wird die gewünschte Variable nicht angezeigt, muss zunächst der Scope auf den entsprechenden Prozess gesetzt werden, in dem die Variable definiert ist (Befehl „SetScope“ im Menü „Examine“).
  • Symbol-Breakpoint: Ein weiterer interessanter Breakpoint ist der „Symbol-Breakpoint“. Dieser wird ausgelöst, wenn der Simulator beim Ablauf ein zuvor festgelegtes SDL-Symbol erreicht. Dazu wählt man im Menü „Breakpoint“ den Befehl „Connect sdle“ aus. Anschließend kann man dann im SDL-Editor das gewünschte Symbol markieren und mit dem Befehl „Set Breakpoint“ im Menü „Breakpoint“ des SDL-Editors das SDL-Symbol festlegen bei dem ein Breakpoint eingerichtet werden soll.

Übung 4: Breakpoints

Anhand der folgenden Befehle soll die Handhabung mit Breakpoints geübt werden:
  • Go
  • Break
  • Set Output-Breakpoint auf das 5. MDatResp
  • Go
  • Remove OutoutBreakpoint
  • Set Variable-Breakpoint auf Variable idu (destination)
  • Go

2.3.4 Skripte (Makros)

Nachdem das Organizer Fenster geöffnet wurde, findet man die Struktur in Abb. 3 vor:
  • Im Bereich „SDL System Structure“ befinden sich alle zum System gehörenden SDL-Blöcke mit den darin enthaltenen Prozessen.
  • Direkt unter den SDL-Blöcken folgen Skripte.
In den Skripten sind Befehlsabläufe gespeichert. Sie dienen der Beschleunigung der Messungen und vereinfachen Ihnen die Konfiguration erheblich. In unserem Fall wurden Skripte vorbereitet, die das Verhalten des „Send-and-Wait“-Protokolls unter verschiedenen Fehlern im Medium (Skripte: packet_reliable, packet_lose, packet_reorder und packet_duplicate) mittels des Simulators analysieren. Durch Doppelklick auf eines dieser Skripte öffnet sich der SDL-Editor, um den Inhalt anzuzeigen und editieren zu können.


Abb. 6: Inhalt eines Skriptes packet_lose

Abb. 6 zeigt beispielhaft den Aufbau des Skripts packet_lose. Wie in Abb. 6 zu erkennen ist, sind im Skript genau die Befehle enthalten, die in den vorangegangenen Abschnitten verwendet wurden. Beispielsweise wird der Befehl „Next-Transition;“ verwendet um die Start-Transition von allen im System enthaltenen Prozessen ausführen zu lassen. Anschließend wird der Wert der Variablen msg_errs des Prozesses msg_hazarddemon verändert. Bevor die Simulation mit dem „Go“-Befehl gestartet wird, wird ein Breakpoint gesetzt, damit die Simulation nicht endlos läuft. Zum Ausführen eines Skriptes ist das Skriptmittels rechtem Mausklick zu markieren. Im sich öffnenden Menü ist unter „Simulator Test“, dann „Existing Simulator...“ anzuklicken und das aktuelle System auszuwählen. Hierauf öffnet sich das Fenster zur Auswahl des Skripts (siehe Abb. 7).


Abb. 7: Auswahl des zu verwendenden Skriptes
Nachdem das Skript ausgewählt wurde, startet startet die Ausführung sofort. Sobald das „Organizer Log“ Fenster im Vordergrund erscheint, ist das Skript erfolgreich ausgeführt worden.

2.4 Simulation des „Send-and-Wait“- Protokolls

Beim Entwickeln einer Protokollsoftware stellt sich die Frage, mit welcher Protokolltechnik die angestrebte QoS sichergestellt werden kann. Dazu ist es erforderlich, verschiedene Protokolltechniken anhand einheitlicher Kriterien miteinander zu vergleichen. Zwei Kriterien, die großen Einfluss auf die QoS-Parameter (Error Probability und Throughput) haben, sind hierbei Effektivität und Effizienz der Protokolltechnik. Unter Effektivität (auch: Robustheit, Resistenz) sollen hier die Fähigkeiten der Protokolltechnik verstanden werden, auftretende Fehler zu erkennen und zu beheben, d.h. alle entgegengenommenen Daten in der richtigen Reihenfolge, lückenlos und ohne Verdoppelungen auszuliefern. Hinter Effizienz verbirgt sich die Fragestellung, wie gut das Protokoll die vorhandene Bandbreite im Übertragungskanal ausnutzt (siehe Halsall [2]). Oder anders formuliert: Wie schnell kann mit diesem Protokoll (bei gegebener Bandbreite) eine bestimmte Menge Daten übertragen werden. Für die Bearbeitung der folgenden Aufgabe soll für das Effizienzkriterium diese zweite Definition benutzt werden.

2.4.1 Aufgabe 1: Einfluss von Fehlerarten im Medium

Es sind Simulationen für den „reliable mode“ und für alle 6 im Medium-Service auftretenden Fehlerarten durchzuführen:

Bei welchen Fehlerarten kommt es zu Fehlern im von der destination empfangenen Datenstrom und was sind das dort für Fehler?

Mit Hilfe des Simulators soll die Zeitdauer ermittelt werden, die das „Send-and-Wait“- Protokoll benötigt, um 50 Datenpakete zu übertragen - jeweils einmal für „reliable mode“, MsgLose, MsgDup und RespLose, RespDup. Zusätzlich ist jeweils der Wert der Variable errcnt aus dem destination-Prozess zu notieren. Die Ergebnisse sind hinsichtlich Effektivität und Effizienz des Protokolls bei Auftreten von unterschiedlichen Fehlern zu interpretieren.

Um die Messungen zu beschleunigen, bietet es sich an die vorbereiteten Skripte zu verwenden. Die Skripte stellen unter anderem die gewünschte Fehlerart ein und setzen einen Breakpoint auf das 50. Auftreten des Signals DataInd im destination Prozess.

Die Skripte modifizieren die Variable msg_errsimcode im Prozess msg_hazarddeamon. Durch die Modifikation der Variablen msg_errsimcode werden die Pakete (Daten) verdoppelt, zerstört usw. . Um die Quittungen (ACKs) zu modifizieren, sind keine Skripte vorhanden. Man kann zwei kleine Änderungen in den vorhandenen Skripten vornehmen, damit nicht die Pakete sondern die Quittungen (ACKs) modifiziert werden:

  • Die Variable msg_errsimcode wird in die Variabel resp_errsimcode umgenannt.
  • Damit der richtige Prozess gefunden wird, muss zusätlich der „Scope" auf den Prozess resp_hazarddeamon gesetzt werden. Dies wird darurch erreicht, dass die Zeile Set-Scope msg_hazarddemon; in Set-Scope resp_hazarddemon; geändert wird.

Die MSC-Logs („Block Trace“) der von „Send-and-Wait“ nicht erkannten Medium-Fehlerarten sollen gespeichert werden. Gehen Sie dabei wie folgt vor:

  • Klicken Sie im MSC-Editor auf „File“
  • Dann „Print...“
  • Wählen Sie anschließend das gewünschte Dateiformat und den Speicherort aus.
  • Am Besten ist hierfür das Dateiformat "eps" geeignet, da hierbei der gesamte Trace in einer einzelnen Vektorgrafik gespeichert wird. Mit dem von uns bereitgestellten Skript "eps2pdf_kn.sh (input.eps) [output.pdf]" kann diese Datei einfach in das pdf Format überführt werden. Alternativ können sie auch eine seitenweise Ausgbabe mit dem "ps" Dateiformat erhalten. Diese können sie mit "ps2pdf (input.ps) [output.pdf]" auf gleiche Weise in das pdf Format überführen. Es gibt außerdem auch die Möglichkeit eine png Datei (inklusive html zu Darstellung) zu erzeugen.

2.4.2 Aufgabe 2: Einfluss der Größe des Retransmission-Timers

Zusätzlich sollen bei einer fehlerfreien Übertragung dieselben „Messungen“ für verschiedene Timeout-Werte im snw_transmitter durchgeführt werden. Auch hier sollen die Werte der Variablen now und errcnt ermittelt werden. Dabei sollen Werte für die Variable d verwendet werden die im Bereich 0.5 - 4 liegen

Ändern Sie für die Bearbeitung dieser Aufgabe den Wert d des Timers in den jeweiligen Skripten und führen diese anschließend aus. Die Ergebnisse sind bezüglich Effizienz und Effektivität des Protokolls bei unterschiedlichen Timerwerten zu interpretieren. Gibt es bei realen Anwendungen so etwas wie einen optimalen Wert für den „Retransmission Timer“?