-
Die
Erfindung betrifft das technische Gebiet der Datenkommunikation
in einem Netzwerk, insbesondere in einem Heimnetzwerk.
-
Hintergrund der Erfindung
-
Zur
Vernetzung von Geräten
im Heimbereich sind Heimnetzwerke bekannt. Die miteinander verbundenen
Geräte
können
aus dem Unterhaltungselektronikbereich stammen, wie z. B. Fernsehgerät, Videorekorder,
DVD-Spieler, Satelliten-Empfangsgerät, CD-Spieler,
MD-Spieler, Verstärker,
Camcorder usw. In diesem Zusammenhang wird auch ein Personalcomputer
erwähnt,
der heute ebenfalls als Gerät der
Unterhaltungselektronik angesehen werden kann.
-
Für die Vernetzung
von Geräten
aus dem Unterhaltungselektronik-Bereich wurden von der Industrie
entsprechende Kommunikationssysteme entwickelt. Gedacht ist dabei
in erster Linie an die drahtgebundene Vernetzung von Geräten, und
hier im besonderen mit Hilfe des sogenannten IEEE1394-Bussystems, mit dem
es möglich
ist, Daten mit sehr hoher Datenrate zwischen den einzelnen Netzwerkstationen
auszutauschen. Die bislang verbreiteten IEEE-1394-Schnittstellen unterstützen in
der Regel die spezifizierten Datenübertragungsgeschwindigkeiten
S100, S200, S400. Dabei bedeutet S100 eine Datenübertragungsrate von 100 Mbit/s.
S200 bedeutet entsprechend eine Datenübertragungsrate von ca. 200
Mbit/s und S400 entsprechend 400 Mbit/s. Durch Erweiterungen des
IEEE-1394-Standards wurden sowohl niedrigere Datenraten, S25 und
S50 als auch höhere
Datenraten, S800, S1600, S3200 ermöglicht. Solch hohe Datenraten
sind insbesondere für
den Austausch von Daten zwischen Unterhaltungselektronikgeräten erforderlich.
Eine typische Anwendung besteht darin, daß bei einer Video/Audioquelle
ein Titel abgespielt wird, entweder Video/Audioquelle ein Titel
abgespielt wird, entweder Videofilm oder Musikstück und der zugehörige Datenstrom an
ein weiteres Unterhaltungselektronikgerät bzw. mehrere Unterhaltungselektronikgeräte als Datensenke/en übertragen
wird. Für
diesen Anwendungsfall wird zwischen den betreffenden Geräten, die
miteinander Daten austauschen, eine Datenverbindung eingerichtet. Über diese
Datenverbindung werden regelmäßig Datenpakete übertragen.
Diese Form der Datenübertragung
ist in dem IEEE-1394-Standard als
isochrone Datenübertragung
bezeichnet, bei der regelmäßig, in
bestimmten Zeitabständen,
Daten von der Datenquelle zu der Datensenke bzw. den Datensenken übertragen
werden.
-
Für die Datenkommunikation
in einem IEEE-1394-Netzwerk ist bei jeder Netzwerkstation eine IEEE-1394-Schnittstelle
erforderlich. In dieser Schnittstelle sind nur die unteren beiden
Schichten entsprechend des OSI-Schichtenmodells der Datenkommunikation,
nämlich
Bit-Übetragungsschicht (Physical
Layer) und Datensicherungsschicht (Data Link Layer) mit Hardware
realisiert. Die darüber
liegenden Schichten, davon insbesondere ein sogenannter „Transaction
Layer" sind meist
mittels Software realisiert. Der in Software realisierte Protokollstapel,
der mit einem Anwendungsprogramm zusammenarbeitet, wird auch als
Treiberprogramm der Busschnittstelle bezeichnet. Daten werden zwischen zwei
Netzwerkstationen mit sogenannten Anforderungs(request)- und Antwortpaketen
(response) ausgetauscht.
-
Erfindung
-
Die
prinzipielle Kommunikation zwischen einem Treiberprogramm und einem
Anwendungsprogramm nach dem Empfang von Anforderungs/Anwortpaketen
ist eine Benachrichtigung des Anwendungsprogramms seitens des Treiberprogramms
mit nachfolgender Reaktion des Anwendungsprogramms in Form von Aufrufen
einer oder mehrerer API-Funktionen des Treiberprogramms. Die Benachrichtigung erfolgt
dabei durch das Signalisieren mittels eines Semaphor, das von dem
Anwendungsprogramm bei seiner Anmeldung übergeben wurde.
-
Ist
die Reaktion des Anwendungsprogramms falsch bzw. bleibt die Reaktion
komplett aus, so bleiben innerhalb des Treiberprogramms wichtige
Ressourcen (insbesondere Speicherbelegungen) besetzt. Treten derartige
Fehlreaktionen beispielsweise durch ein falsch programmiertes Anwendungsprogramm
in häufiger
Wiederholung auf, so kann dies zu Verzögerungen oder sogar zur Unbenutzbarkeit
des Treiberprogramms im laufenden Betrieb führen.
-
Dieses
Problem wird erfindungsgemäß durch
die Maßnahmen
der unabhängigen
Ansprüche 1
und 11 gelöst.
Innerhalb einer Netzwerkstation ist eine Überwachungsinstanz installiert,
die in regelmäßigen Zeitabständen überprüft, ob die
aufgerufenen Transaktionen auch innerhalb eines vorgegebenen Zeitrahmens
ordnungsgemäß abgearbeitet
wurden. Wenn dabei Zeitüberschreitungen
festgestellt werden, wird die zugehörige Datenübertragung abgebrochen und
die durch die Transaktion/Datenübertragung
belegten Ressourcen wieder freigegeben.
-
Die Überwachungsinstanz
kann im Treiberprogramm enthalten sein. Damit kann das Treiberprogramm
auf eine fehlerhaft programmierte bzw. zu langsam arbeitende Anwendungssoftware
flexibel reagieren. Es ist somit ein tolerantes Fehlerverhalten des
Treiberprogramms realisiert und es wird ein Totalausfall der Netzwerkstation
im Rahmen der Möglichkeiten
vermieden. Beispielsweise kann die Netzwerkstation noch mit einer
anderen Anwendung weiterarbeiten, ohne daß die fehlerhafte Anwendung
die Teilnahme am Datenaustausch im Netzwerk vollständig unterbindet.
Durch diesen Schutzmechanismus ist gewährleistet, daß das Treiberprogramm
stets mit einem konstanten Satz an Ressourcen uneingeschränkt betriebsbereit ist.
Dies ist gerade dann wichtig, wenn das Treiberprogramm auf einer
Plattform mit begrenzten Ressourcen, wie es bei Unterhaltungselektronikgeräten üblich ist,
zum Einsatz kommt.
-
Durch
die in den abhängigen
Ansprüchen aufgeführten Maßnahmen
sind weitere vorteilhafte Weiterbildungen und Verbesserungen möglich.
-
Für die Erfassung
aller zu einer Transaktion gehörenden
Daten und Kontrollinformationen wird für jede Transaktion ein solches
Transaktionsobjekt angelegt und in einer zentralen Liste für alle aktiven Transaktionen
verwaltet.
-
Das Überschreiten
des Zeitrahmens kann besonders einfach dann überprüft werden, wenn der jeweilige
Startzeitpunkt einer Transaktion als Kontrollinformation in einem
der Transaktion zugeordneten Transaktionsobjekt festgehalten wird.
-
Für die Durchführung von
Transaktionen sind in dem Treiberprogramm eine oder mehrere Warteschlangen
eingerichtet, in die Transaktionsobjekte je nach ihrem aktuellen
Verarbeitungsstatus einsortiert werden können. Sobald die Überschreitung
des Zeitrahmens für
eine solche Transaktion festgestellt wurde, ist es vorteilhaft,
das Transaktionsobjekt für
diese Transaktion aus der jeweiligen Warteschlange zu entfernen
und mit einer anschließenden
Terminierung des Transaktionsobjektes das Transaktionsobjekt aus
der zentralen Liste zu entfernen und den Speicher freizugeben und
verfügbar
zu machen.
-
Die
Startzeitpunkte der jeweiligen Transaktion sowie die verschiedenen
Verarbeitungsschritte bei der Durchführung einer Transaktion werden
in vorteilhafter Weise in den Kontrollinformationen des Transaktionsobjektes
registriert.
-
Die
erfindungsgemäße Maßnahme kann vollständig in
dem Treiberprogramm für
eine Netzwerkschnittstelle implementiert sein. In diesem Fall kann
die Erfindung in einem Computerprogrammprodukt bestehen, welches
in den internen Speicher einer Netzwerkstation ladbar ist.
-
Zeichnungen
-
Die
Erfindung wird im folgenden anhand von Ausführungsbeispielen unter Bezugnahme
auf Zeichnungen näher
erläutert.
Jeweils zeigen:
-
1 die
konkrete Baumstruktur eines beispielhaften IEEE-1394-Netzwerkes;
-
2 den
prinzipiellen Ablauf einer Anforderungs/Antworttransaktion;
-
3 die
sogenannte Protokoll-Architektur für eine Netzwerkstation gemäß IEEE-1394-1995-Standard;
-
4 die
erfindungswesentlichen Komponenten eines Treiberprogramms sowie
dessen Zusammenarbeit mit einem Anwendungsprogramm;
-
5 einen
beispielhaften Aufbau eines erfindungsgemäßen Transaktionsobjektes;
-
6 ein
Zustandsdiagramm der erfindungsgemäßen Überwachungsinstanz und;
-
7 ein
prinzipielles Ablaufdiagramm für die Überwachungsinstanz
innerhalb des Treiberprogramms.
-
Ausführungsbeispiele der Erfindung
-
In
der 1 ist ein Beispiel eines IEEE-1394-Netzwerkes
dargestellt. Die einzelnen Geräte
sind wie bei einer Baumstruktur miteinander verbunden. Dabei handelt
es sich bei dem Gerät
mit der Bezugszahl 10 um einen Drucker. Die Bezugszahl 11 bezeichnet
einen digitalen Videoredorder DVR. Es kann sich beispielsweise um
ein digitales Satellitenempfangsgerät handeln mit integriertem Festplattenrekorder.
Die Bezugszahl 12 bezeichnet eine Videokamera in Form eines
digitalen Camcorders CAM z. B. DV-Camcorder. Die Bezugszahl 13 bezeichnet
ein digitales TV-Gerät, z. B.
Plasma-Display. Mit der Bezugszahl 14 ist ein DVD-Abspielgerät bezeichnet.
Wie gezeigt, sind alle im Netzwerk befindlichen elektronischen Geräte mit einer
sogenannten 3-Port-IEEE-1394-Schnittstelle ausgestattet. Bei den
Geräten 12, 13, 14 ist
jeweils nur Port 0 belegt, bei dem Drucker 10 sind
die Ports 1 und 2 belegt, und bei dem digitalen
Videorekorder 11 sind alle 3 Ports belegt. Die
Abkürzung
IRM bei dem Drucker 10 deutet darauf hin, daß dieser
Drucker 10 als Isochronus-Resource-Manager, also als Busverwaltungseinheit
für den
isochronen Datenverkehr für
das Netzwerk operiert. Die Bezeichnung Root stellt zusätzlich klar,
daß der
Drucker 10 der Wurzelknoten in dem gezeigten Netzwerk ist.
-
2 zeigt
den prinzipiellen Ablauf einer Anforderungs/Antworttransaktion im
IEEE1394-Netzwerk. Mit den Bezugszeichen REQ TL ist die Transaktionsschicht
in dem die Transaktion auslösenden Gerät bezeichnet.
Mit dem Bezugszeichen RESP TL ist die Transaktionsschicht in der
Netzwerkstation, von der angeforderte Daten geliefert werden sollen, bezeichnet.
Die Transaktion wird durch ein Anwendungsprogramm bei der Transaktionsschicht
des Anforderungsgerätes
angefordert. Dies ist durch den in 2 gezeigten
Service TR-DATA.req angedeutet. Dieser Service
wird in der Transaktionsschicht REQ TL in Kommandos für die Datensicherungsschicht umgesetzt,
welche daraus wiederum zu einem Datenpaket weiterverarbeitet werden,
welches dann über die
Bit-Übertragungsschicht
des sendenden Gerätes
geht und zu dem Empfangsgerät über die Busverbindung
weitergeleitet wird. Anschließend
erfolgt eine Benachrichtigung der Transaktionsschicht in der Zielnetzwerkstation.
Die Transaktionsschicht RESP TL bedient sich daraufhin eines Services TR-DATA.ind, um die mit der Transaktion angeforderten
Daten von dem Anwendungsprogramm im Zielgerät anzufordern. Wenn das Anwendungsprogramm
im Zielgerät
ordnungsgemäß arbeitet,
wird es die angeforderten Daten in einem bestimmten Zeitrahmen der
Transaktionsschicht RESP TL über
den Service TR-DATA.resp zur Verfügung stellen.
Diese Daten werden dann zu einem Paket verarbeitet, welches die
Datensicherungschicht des Zielgerätes passiert und über die
Bit-Übertragungsschicht
und das Netzwerkkabel zu der Anforderungsnetzwerkstation übertragen
wird. Nach Benachrichtigung der Transaktionsschicht in der Anforderungsnetzwerkstation seitens
der dortigen Datensicherungschicht erfolgt die Übergabe der angeforderten Daten
an das Anwendungsprogramm mit Hilfe des Services TR-DATA.conf.
Wie gezeigt, werden bei einer solchen Anforderungs/Antworttransaktion
vier Services der Transaktionsschicht benutzt. Weiterhin sind einige Services
der Datensicherungsschicht involviert, die nicht im einzelnen näher erläutert wurden.
-
Die
Protokollarchitektur und die verschiedenen Services sind in der 3 näher dargestellt.
Die beiden Kommunikationsschichten Bit-Übertragungsschicht (Physical
Layer) 20 und Datensicherungsschicht (Link Layer) 21 werden
durch separate Schaltungseinheiten oder eine einzige integrierte
Schaltungseinheit, also mit Hardware realisiert. Die weiteren gezeigten
Schichten, nämlich
Transaction Layer 22, Serial Bus Management 23 und
Application Layer 24 werden üblicherweise mittels Software
implementiert, die dann auf einen leistungsfähigem Mikrocontroller in der
Netzwerkstation ausgeführt
wird. Die einzelnen Komponenten bezüglich Bit-Übertragungsschicht 20,
Datensicherungsschicht 21 sowie Transaktionsschicht 22 sind
in dem IEEE-1394-Standard ausführlich beschrieben
und werden deshalb hier nicht genauer erläutert.
-
Innerhalb
der Schicht für
das Serial Bus Management 23 sind die Komponenten Node
Controller 27, Isochronus-Resource-Manager 26 und Bus Manager 25 hervorgehoben.
In einem IEEE-1394-Netzwerk
sind maximal ein Bus Manager 25 und maximal ein Isochronus-Resource
Manager 26 zu einer Zeit aktiv, selbst wenn mehrere Netzwerkknoten
die jeweilige Funktion ausführen
können.
Beide Funktionen sind gemäß IEEE-1394-Standard jedoch optional.
-
In
der 4 bezeichnet die Bezugszahl 24 die Anwendungsschicht,
d. h. dort ist ein oder mehrere Anwendungsprogramme für die Netzwerkteilnehmerstation
vorhanden. Das Anwendungsprogramm für das DVD-Abspielgerät 14 dient
zur Koordinierung des Abspielvorgangs, also MPEG-Dekodierung, Titelauswahl, Aufbau der
Bedienmenüs
z. B. für
Titelauswahl, Spracheinstellung, Untertiteleinblendung etc. Unterhalb
der Anwendungsschicht 24 ist das Treiberprogramm 30 für die Busschnittstelle
angeordnet. Durch Pfeile ist angedeutet, daß das Anwendungsprogramm mit
dem Treiberprogramm 30 kommuniziert. Das Treiberprogramm
besteht wie zuvor beschrieben aus Transaktionsschicht und dem Serial Bus
Management. Zusätzlich
sind erfindungsgemäß noch einige
weitere Komponenten im Treiberprogramm 30 enthalten, die
in der 4 einzeln dargestellt sind. Die Bezugszahl 31 bezeichnet
eine Überwachungsinstanz.
Diese dient zur periodischen Überprüfung der
angeforderten Transaktionen im Hinblick auf Überalterung. Die genaue Funktionsweise
dieser Instanz wird nachfolgend noch näher erläutert.
-
Mit
der Bezugszahl 32 ist die globale Transaktionsobjektliste
gekennzeichnet. Die globale Transaktionsliste enthält die Transaktionsobjekte
aller zu dieser Zeit aktiven asynchronen Transaktionen. A bis G sollen
beispielhaft alle Transaktionsobjekte aller aktiven Transaktionen
darstellen.
-
Die
Transaktionsobjektliste ist wie dargestellt als doppelt verkettete
Liste von Transaktionsobjekten ausgebildet. Für isochoronen Datenverkehr
werden keine Transaktionsobjekte verwendet.
-
Mit
der Bezugszahl 33 ist eine Warteschlange bezeichnet, in
die die Transaktionsobjekte einsortiert werden, die empfangene Anforderungstransaktionen
von anderen Netzwerkstationen beschreiben. Diese Transaktionsobjekte
können
Daten repräsentieren,
die entweder über
das Netzwerk zu dieser Station gesendet wurden oder von außen von
ihr angefordert wurden. In 4 sind das
beispielhaft die Transaktionsobjekte B, C und E.
-
Mit
der Bezugszahl 34 ist eine Warteschlange bezeichnet, in
die die Transaktionsobjekte einsortiert werden, die empfangene Beantwortungstransaktionen
repräsentieren,
d.h. deren Transaktion über den
Bus erfolgreich abgeschlossen wurde.
-
Diese
Transaktionsobjekte beziehen sich somit auf Daten, die von der stationseigenen
Anwendungssoftware zu einer anderen Netzwerkstation versendet wurden,
oder von einer anderen Netzwerkstation angefordert wurden, wobei
diese andere Station die Rückmeldung
geliefert hat, dass die Daten angekommen sind oder die gewünschten
Daten in der Rückantwort
enthalten sind.
-
Die
stationseigene Anwendungssoftware muss dann noch die Transaktion
abschließen
(die gewünschten
Daten verarbeiten oder die gesendeten Daten werden aus einem Speicherbereich
(Sendepuffer) herausgenommen.
-
Eine
dritte Warteschlange 35 ist noch vorhanden, in die solche
Transaktionsobjekte einsortiert werden, die zwischenzeitlich zur
Verarbeitung an die Applikation weitergeleitet worden sind, und
jetzt auf die Bestätigung
der vollständigen
Bearbeitung warten. Die Transaktionsobjekte in dieser Warteschlange waren
zuvor in der ersten Warteschlange 33 einsortiert, repräsentieren
somit Anforderungstransaktionen. Im Beispiel der 4 sind
das die Transaktionsobjekte D und F.
-
Die
Transaktionsobjekte in den Warteschlangen 33–35 sind
ebenfalls als doppelt verkettete Listen, also mit den entsprechenden
Zeigern auf den Beginn bzw. das Ende des nachfolgenden bzw. des vorhergehenden
Transaktionsobjektes ausgebildet.
-
Der
Aufbau eines Transaktionsobjektes ist in 5 genauer
dargestellt. Mit der Bezugszahl 40 ist ein Feld für den Zeiger
auf das vorhergehende Transaktionsobjekt in der Liste oder Warteschlange
bezeichnet. Mit der Bezugszahl 43 ist ein Feld für den Zeiger
auf das nachfolgende Transaktionsobjekt in der Liste oder Warteschlange
bezeichnet. In dem Datenfeld 41 ist Platz für eine Anzahl
von Verwaltungsdaten. Solche sind z.B. der Startzeitpunkt zu dem
das Transaktionsobjekt angelegt wurde. Optional der Stopzeitpunkt
an dem die Transaktion seitens des IEEE 1394 Bus vollständig ausgeführt wurde.
Zusätzliche
Verwaltungsdaten betreffen Einträge
dafür, welche
Warteschlangen das Transaktionsobjekt durchlaufen hat bzw. in welcher
es sich aktuell befindet. Dafür
können
einzelne Statusbits als Information ausreichen. Weitere Beispiele
von Verwaltungsdaten sind: Mit der Bezugszahl 42 ist noch
ein Feld für
einen Zeiger markiert, der auf die eigentlichen Nutzdaten 44 des
Transaktionsobjektes zeigt. Einer Transaktion kann eine variable
Anzahl von Nutzdaten zugeordnet sein. Deshalb ist es von Vorteil,
wenn im Transaktionsobjekt nicht die Nutzdaten selbst enthalten
sind, sondern jeweils nur ein Zeiger auf diese.
-
Der
Startzeitpunkt des Transaktionsobjektes bleibt so lange unverändert, bis
die Transaktion vollständig
abgeschlossen wurde. Wenn das der Fall ist, wird das Transaktionsobjekt
in der globalen Transaktionsobjektliste 32, sowie eventuell
aus den Warteschlangen, sowieso gelöscht. Für die Buszykluszeit sind 32
Bits erforderlich. Anhand der Bit-Zustände in diesem Objekt kann die Überwachungsinstanz 31 jederzeit
feststellen, wieweit die Transaktion gediehen ist. Zusätzliche
Einträge
in dem Transaktionsobjekt 37 sind möglich, was in 5 angedeutet
ist.
-
Die 6 zeigt
ein Zustandsdiagramm für die Überwachungsinstanz 31.
Darin sind 3 Zustände unterschieden.
Mit der Bezugszahl 50 ist ein Zustand bezeichnet, der während der
Bus Rücksetzphase eingenommen
wird. Während
dieser Phase findet keine Überwachung
von Transaktionen statt. Das Ende der Bus-Rücksetzphase wird seitens des
Treiberprogramms 30 signalisiert. Damit wechselt der Zustand
der Überwachungsinstanz 31 in
einen Wartezustand, der mit der Bezugszahl 51 bezeichnet
ist. Im Wartezustand verbleibt die Überwachungsinstanz eine definierte
Wartezeit. Wenn die Wartezeit abgelaufen ist, wechselt der Zustand
der Überwachungsinstanz 31 zum
eigentlichen Überwachungszustand 52,
in dem die globale Transaktionsobjektliste 32 überprüft wird.
Nachdem alle Transaktionsobjekte in der Liste überprüft worden sind, wechselt der
Zustand der Überwachungsinstanz 31 wieder
in den Wartezustand 51 zurück. Für den Fall, das ein neuer Busrücksetzvorgang
auftritt, wechselt der Zustand des Treiberprogramms in den Zustand
der Bus-Rücksetzphase
zurück.
Die Überwachungsinstanz 31 wechselt
in den internen Zustand „Bus
Reset" (50), wenn
während
der Dauer des Busrücksetzvorgangs ein
Wechsel von dem Wartezustand (51) zu dem Überwachungszustand
(52) stattfinden soll. Der Wartezustand (51) ist
ein Warten an einem Timerelement. Es wird daher oft auftreten, dass
ein Busrücksetzvorgang
einfach „verschlafen" wird. Terminiert das
Timerelement, so wechselt die Überwachungsinstanz
immer sofort in den State „Check" (52), kontrolliert
dort ob gerade ein Busrücksetzvorgang
läuft und wechselt
in diesem Fall in den State „BusReset" (50).
-
Ein
Transaktionsobjekt bleibt so lange in der globalen Transaktionsobjektliste 32,
wie die Transaktion noch gültig
(in Bearbeitung) ist. Zu den Informationen über den augenblicklichen Zustand
der Transaktion können
auch Vermerke gehören,
darüber,
welche Arbeitsschritte die Treibersoftware 30 in Bezug auf
die Abarbeitung der Transaktion bereits ausgeführt hat. Ebenso können dazu
gehören
die bereits erfolgten Reaktionen der Anwendungssoftware in Bezug
auf diese Transaktion.
-
Ein
IEEE1394-Treiber-Programm 30 muß die Anwendungssoftware benachrichtigen,
wenn ein sogenanntes Anforderungspaket auf einen von ihr selbst
verwalteten Adreßbereich
eingegangen ist bzw. ebenfalls auch bei Ankunft eines Antwortpaketes
als Antwort auf eine nichtblockierende Anforderung der Anwendungssoftware.
Die Benachrichtigung erfolgt in beiden Fällen über ein zwischen Anwendungssoftware
und Treiberprogramm ausgetauschtes Semaphor. Die erste Reaktion
des Anwendungsprogramms auf eine Benachrichtigung ist das Aufrufen
der entsprechenden API-Funktion für die Abholung der zur Transaktion
gehörenden
Daten. Das Treiberprogramm 30 hält die zugehörigen Transaktionsobjekte
in den spezifischen Warteschlangen 33 und 34 vor.
Bei einer Benachrichtigung über
eine erfolgreich abgeschlossene nichtblockierende Anforderungstransaktion,
bzw. bei einer Benachrichtigung über
den Zugriff auf einen nicht von der Applikation selbstverwalteten
Adressbereich erfolgt mit dem Aufruf der entsprechenden API-Funktion
ein Herauslöschen
des Transaktionsobjektes aus der Warteschlange 34 oder 33 und
aus der globalen Transaktionsobjektliste 32 mit einer anschließenden Freigabe des
Transaktionsobjektes (Freigabe der Resourcen).
-
Bei
einer Benachrichtigung über
eine eingegangene Anforderungstransaktion auf einen von der Applikation
selbstverwalteten Adressbereich wird das zugehörige Transaktionsobjekt von
der Warteschlange 33 in die Warteschlange 35 verschoben und
der Applikation werden die zugehörigen
Daten übergeben.
Das Vorhandensein in der Warteschlange 35 sowie der Aufruf
der API-Funktion wird durch das Setzen des „bInByApplicationQueue" Flags innerhalb
des Transaktionsobjektes vermerkt. Nach Abarbeitung der Anforderung übergibt
die Applikation die jeweiligen Antwortdaten an die Treibersoftware mit
Aufruf der entsprechenden API Funktion. Innerhalb dieser Funktion
wird das Transaktionsobjekt aus der Warteschlange 35 und
der globalen Transaktionsobjektliste 32 entfernt, die Antwortdaten
werden über
den Bus versendet und das Transaktionsobjekt wird freigegeben.
-
Die
implementierte Überwachungsinstanz 31 sucht
in zeitlich regelmäßigen Abständen in
globalen Transaktionsobjektliste 32 nach Transaktionsobjekten,
die veraltete Anforderungs- und
Antworttransaktionen repräsentieren.
Dies können
Anforderungstransaktionen sein, die von einer anderen Netzwerkstation
nicht rechtzeitig beantwortet wurden, oder Antworttransaktionen,
die nicht rechzeitig zur anfordernden Netzwerkstation gesendet werden
können, bzw.
Antworttransaktionen die nicht rechtzeitig oder überhaupt nicht von der Anwendungssoftware
abgeholt wurden. Dieser Vorgang ist in der 7 näher dargestellt.
Der Start der Überwachungsroutine
ist in 7 mit der Bezugszahl 60 bezeichnet. Im
Schritt 61 wird die Transaktionsobjektliste für Neueinträge/Schreibvorgänge gesperrt.
Im Schritt 62 wird die aktuelle Buszykluszeit des IEEE1394
Busses als Referenzzeit gelesen. Dann wird von der globalen Transaktionsobjektliste 32 das
nächste
noch nicht untersuchte Transaktionsobjekt gelesen. Im Verzweigungsschritt 64 wird überprüft, ob der
gelesene Zeiger auf das Transaktionsobjekt Null ist. Dies würde bedeuten,
dass alle Transaktionsobjekte untersucht sind, wonach die Überwachungsroutine
im Schritt 65 beendet würde.
Wenn der Zeiger nicht NULL ist, wird das nächste durch diesen Zeiger repräsentierte Transaktionsobjekt
untersucht.
-
Im
Schritt 66 wird dazu der im Transaktionsobjekt eingetragene
Wert für
die Stopzeit ausgewertet. Der Transaktion wird eine Stopzeit zugeordnet, sobald
die zugehörige
Transaktion über
den IEEE1394-Bus abgeschlossen ist. Also z.B. bei einer Leseanforderungstransaktion
wird in das Transaktionsobjekt auf der Seite des Senders der Anforderung die
Stopzeit eingetragen, sobald die Leserückantwort über den Bus zu der anfragenden
Station geliefert wurde. In das Transaktionsobjekt auf der Seite
des Empfängers
der Leseanforderung wird die Stopzeit nach dem Absenden der geforderten
Daten über
den Bus eingetragen. Als Stopzeit wird die aktuelle Buszeit seitens
der Transaktionsschicht 22 verwendet. Ist die Stopzeit
gleich Null, heißt
das, die Übertragung über den
Bus ist noch nicht abgeschlossen. In dem Fall verzweigt das Programm
zum Programmschritt 67 in dem von der in Schritt 62 gemessenen Referenz-Buszeit
die eingetragene Startzeit des Transaktionsobjektes abgezogen wird.
Der resultierende Wert wird mit dem sogenannten Split Time-Out Wert
verglichen. Es ist eine Besonderheit bei dem IEEE1394-Netzwerk,
daß Transaktionen
auch zeitlich unterbrochen werden dürfen. Der Split-Time-Out-Wert
legt dann fest, bis zu welchem Zeitpunkt nach einer Anforderung
an die Datensicherungsschicht noch eine Antwort auf diese Anforderung
akzeptiert wird. Spätere
Antworten dürfen
dann nicht mehr von der Datensicherungsschicht weitergeleitet werden.
Da solche Antworten also erst gar nicht zurückgeliefert würden, ist
es ein gutes Abbruchkriterium für
die Transaktion, daß die
Transaktion nicht länger
als diese Split-Time-Out-Zeit dauern darf. Wenn in Abfrage 68 der
Split-Time-Out-Wert noch nicht überschritten
wurde, springt das Programm zum Programmschritt 63 zurück und es
wird das nächste
Transaktionsobjekt überprüft. Anderenfalls verzweigt
das Programm zu Abfrage 69, wo überprüft wird, ob das Transaktionsobjekt
noch in der ersten Warteschlange 33 ist. Wenn ja wird das
Transaktionsobjekt aus dieser Warteschlange 33 entfernt. Dies
geschieht in Programmschritt 70 durch Löschen der Zeiger 40 und 43 und
Rücksetzen
der Einträge
in den Verwaltungsdaten 41. Dazu gehört ebenfalls, dass die Zeiger 40 und 43 der
benachbarten Transaktionsobjekte in der doppelt verketteten Liste
umgetragen werden, so dass eine neue doppelt verkettete Liste entsteht,
ohne das gelöschte
Transaktionsobjekt.
-
Schließlich wird
in Programmschritt 71 das Transaktionsobjekt auch aus der
globalen Transaktionsobjektliste 32 entfernt. Der Speicher
für das Transaktionsobjekt
wird dem System verfügbar
gemacht. Dies kann dadurch geschehen, dass der Zeiger zu dem freigewordenen
Transaktionsobjekt der Speicherverwaltung übergeben wird. Die Überwachungsroutine
verzweigt dann zu dem Programmschritt 63 um das nächste Transaktionsobjekt
in der Liste zu überprüfen.
-
Wenn
in Abfrage 69 festgestellt wird, dass das Transaktionsobjekt
nicht in der ersten Warteschlange 33 enthalten ist, wird
in Abfrage 72 überprüft, ob es
in der dritten Warteschlange 35 eingetragen ist. Dies könnte der
Fall sein, wenn die Applikation Anfragen an einen von ihr selbstverwalteten Adressbereich
nicht rechtzeitig bzw. gar nicht bearbeitet hat. In diesem Fall
wird das Transaktionsobjekt im Programmschritt 73 aus der
dritten Warteschlange 35 entfernt. Dies geschieht wie oben
erläutert. Schließlich wird
das Transaktionsobjekt ebenfalls im Programmschritt 71 aus
der globalen Transaktionsobjektliste gelöscht. War das Transaktionsobjekt wie in
Abfrage 72 festgestellt weder in der ersten noch in der
dritten Wartschlange eingetragen, wird es nur aus der globalen Transaktionsobjektliste
entfernt.
-
Wenn
in Abfrage 66 erkannt wird, dass in dem Transaktionsobjekt
eine Stopzeit eingetragen ist, folgt die Überprüfung der Warteschlangen einem anderen
Pfad. In dem Fall ist klar, dass die Transaktion über den
Bus stattgefunden hat. Das Transaktionsobjekt könnte zusätzlich in der ersten 33 oder
der zweiten Warteschlange 34 sein. In der dritten Warteschlange 35 könnte es
nicht sein, weil bei den Transaktionen mit eingetragener Stopzeit
nur noch eine Benachrichtigung zur Applikation erfolgen muss, dass
die Daten übertragen
oder eingetroffen sind (Warteschlange 34), bzw. ein Zugriff
auf einen von der Treiberinstanz verwalteten Adressbereich der Applikation
stattgefunden hat (Warteschlange 33). Das Ereignis (Event)
mit dem die Benachrichtigung der Applikation erfolgt, ist in dem
Transaktionsobjekt eingetragen. Das Transaktionsobjekt bleibt in
den jeweiligen Warteschlangen, bis die Applikation die Benachrichtigung
mit dem API Funktionsaufruf „GET Asynchronous
Operation Event" abholt.
-
Zunächst wird
in Programmschritt 74 die Differenz zwischen aktueller
Referenz-Buszeit aus Schritt 62 und Stopzeit errechnet.
In Abfrage 75 wird überprüft ob das
Transaktionsobjekt bereits veraltet ist. Dazu wird die ermittelte
Differenz mit einem Schwellwert, z.B. ts = 1s verglichen. Ist der
Schwellwert ts noch nicht überschritten,
wird die Überprüfung abgebrochen
und zum Programmschritt 63 gesprungen. Wenn der Schwellwert
ts überschritten
ist, wird geprüft,
ob das Transaktionsobjekt in der Warteschlange 34 enthalten
ist. Wenn ja, wird das Transaktionsobjekt im Programmschritt 77 aus
der Warteschlange 34 entfernt. Wenn nein, wird in Abfrage 78 überprüft, ob das
Transaktionsobjekt noch in der ersten Warteschlange 33 eingeordnet
ist. Das Transaktionsobjekt wird, wenn nötig in Programmschritt 79 aus
der ersten Warteschlange 33 ausgetragen. Schließlich erfolgt
die Austragung aus der globalen Transaktionsobjektliste 32 in
Programmschritt 71, wie oben beschrieben.
-
Die
Erfindung kann in vorteilhafter Weise insbesondere bei einem IEEE1394-Netzwerk
angewendet werden. Sie ist aber nicht auf diese Anwendungsmöglichkeit
beschränkt.
Vielmehr kann die Erfindung auch bei anderen Netzwerksystemen zum
Einsatz kommen.
-
Die
Erfindung kann auch in Form eines Computerprogrammproduktes zum
Einsatz kommen, welches in den internen Speicher einer Netzwerkstation ladbar
ist. Ein solches Computerprogrammprodukt kann auf üblichen
Datenträgern
im Handel erhältlich sein,
also insbesondere CD/DVD ROM oder Diskette oder Speicherkarte. Es
kann aber auch über
Kommunikationsschnittstellen nachgeladen werden.