Distributed-Processing
Implementierung
Implementierung
Die vollständige Implementierung der Client-Server Lösung unter TCP basiert auf drei TCL Befehlen, die ein Neuzugang der Version 7.5 der Tool Command Language sind. Aufgrund der Bedeutung dieser Befehle für das Projekt, sind diese einer eingehenden Untersuchung unterzogen worden, und sollen Erwähnung finden.
Die Interpreterbefehle mit ihrer Syntax sind
Der socket-Befehl erlaubt nicht nur die Erzeugung eines horchenden (listening) sockets für einen festgelegten Port, um einen Server zu konstruieren, sondern auch die Kreation eines passenden Kommunikationsendes für einen Client.
Das socket-Kommando verlangt als Parameter eine TCL-Anweisung ( command), die ausgeführt wird, wenn ein Client beim Server ,,anklopft`` als auch den Port (port), über den sich jegliche Klienten anmelden dürfen. Die Anmeldung geschieht von der Clientseite aus durch Aufruf des socket-Befehls unter Angabe des Serverhosts und Listening-Ports.
Das Anmeldeprocedere, das zu einer eindeutigen Verbindung führt, wird vom TCL-Interpreter übernommen. Der Klient kontaktiert den Server am listening-port, der ihm bekannt ist. Der Server teilt dem Klienten nur eine neue exklusive Verbindung mit, über die zukünftig kommuniziert wird. Anschließend wird der listening-port wieder freigegeben, damit auch anderen Clients die Möglichkeit haben sich anzumelden.
Nachdem vom TCL-Interpreter eine neue Verbindung (mit einer neuen Portnummer) ausgehandelt wurde, wird die TCL-Anweisung command, die bei der Einrichtung des Serversockets als Parameter angegeben war, mit der Angabe des neuen Sockets sowie weiteren Informationen über den Client als Ereignis ( event) aufgerufen.
Das aufgerufene Kommando command ist in der Regel der Name einer TCL-Prozedur, in der nun über die sockets ebenso wie mit einem Dateideskriptor durch Lesen und Schreiben Daten ausgetauscht werden können. Der Client erhält diesen Socketdeskriptor unmittelbar als Rückgabewert.
Der Server könnte noch in der aufgerufenen Prozedur mit der Kommunikation beginnen. Dies ist jedoch nicht in allen Fällen zweckmäßig, da ein unmittelbarer Datenaustausch nicht erforderlich sein muß, und zunächst mit dem TCL-Programm fortgefahren werden soll. In diesem Fall bietet das Kommando fileevent Abhilfe. Hiermit läßt sich festlegen, daß nur dann jeweils ein Skript aufgerufen werden soll, wenn Daten am socket anliegen oder dieser beschrieben werden kann. In diesen Fällen wird jeweils ein Ereignis ausgelöst, das die Kommunikation abwickelt.
Mit Hilfe des fconfigure Kommandos können Eigenschaften von Datei- und Socketdeskriptoren verändert werden. Wesentliche Eigenschaften sind die Art der Umsetzung von Neuzeilen, Puffer und die Festlegung von blockierendem oder unblockierendem Modus. Der VDM Server arbeitet auschließlich im voreingestellten blockierendem Modus, der sich dadurch auszeichnet, daß auf Eingaben gewartet wird. Der nichtblockierende Modus kehrt sofort ohne Resultat zurück, wenn keine Daten zu lesen sind. Ferner wird vom VDM Server die Pufferung ausgeschaltet, so daß sich ein Durchspülen der Leitung erübrigt.
Der TCL-Interpreter stellt kein Multitasking zur Verfügung, gestattet aber, daß zwischen der Abarbeitung von zwei Befehlen das laufende Programm unterbrochen wird, um vorübergehend an einer anderen Stelle weiterzuarbeiten. Das Programm wird jedoch nicht immer selbsttätig unterbrochen, sondern dazu Bedarf es der Ausführung des TCL-Kommandos update durch das laufende Programm, welches intern über die Funktion Tcl_DoOneEvent ein Ereignis aus der Warteschlange abarbeitet, in die alle Ereignisandorderungen gestellt werden.
Für einen Server, dessen Aufgabe es ist, auf die Wünsche der Clients zu reagieren, würde dies in der Zeit wo kein Wunsch vorliegt bedeuten, in einer Endlosschleife fortwährend den Befehl update auszuführen. Dies ist sehr rechenzeitintensiv.
Eine bessere Lösung ist es, den Server update nur dann ausführen zu lassen, wenn tatsächlich ein Ereignis vorliegt und ansonsten am besten stillzustehen. Dies kann mit dem TCL-Befehl vwait realisiert werden, der als Parameter eine globale Variable erwartet und solange an dieser Stelle ohne nennenswerten Verbrauch von Rechenzeit verbleibt, bis diese Variable durch eine Ereignisprozedur auf einen beliebigen Wert gesetzt wird, auch wenn sich der Inhalt der Variable dadurch nicht verändert. Entscheidend ist lediglich der Zugriff. vwait stoppt lediglich das aktuelle Programm, läßt aber weiterhin die Abarbeitung eines einzigen Events zu.
Die Endlosschleife des Servers muß zum sparsamen Umgang mit Rechenzeit daher folgendes Aussehen haben:
while {1} { update ; vwait var }
Um zu verhindern, daß die Abarbeitung von Ereignissen ins Stocken kommt, ist es erforderlich, daß nach jedem Ereignis update ausgeführt wird. Dies wird dadurch gesichert, daß jede Ereignisprozedur die globale Variable var am Ende der Bearbeitung setzt.
Der Zugriff auf die Sitzungsschicht erfolgt durch einen SSAP (Session Service Access Point). Der SAP der in TCL implementierten Sitzungsschicht besteht aus einer Liste, in der allerdings nur die Rückruf (Callback) Funktionen enthalten sind, die selbstätig von der Sitzungsschicht aufgerufen werden, um die über ihr liegende Schicht mit Daten zu versorgen. Datenverkehr in der umgekehrten Richtung findet durch Aufruf der Dienstelemente der Sitzungschicht statt, dessen TCL-Prozedurname der OSI-Definition entspricht, wie beispielsweise CONNECT.request.
Als Prozeduren für die Liste, welche den SAP darstellt, wird erwartet:
Den einzelnen Funktionen sind Argumente, die sie für die Kommunikation und andere Zwecke benötigen, vorbestimmt, die an dieser Stelle jedoch keine Erwähnung finden sollen. Zu beachten ist jedoch, daß das alle Funktionen dazu verpfllichtet sind, selbst update auszuführen oder ein Signal für eine Serverschleife zu setzen, die dies tut.
Distributed-Processing
Implementierung
Implementierung
VDM Class Library