-
Die
vorliegende Erfindung bezieht sich auf ein Kommunikationsbussystem
nach dem Oberbegriff des Anspruchs 1.
-
Die
vorliegende Erfindung bezieht sich ebenfalls auf eine Durchführungsstation
zur Verwendung in einem derartigen Kommunikationsbussystem.
-
Das
IEEE 1394 Bussystem ist ein Kommunikationsbussystem (das als ein
1394-System bezeichnet wird) das angewandt werden kann zum Verbinden
von Stationen wie Fernsehgeräten
und Videorecordern. Abschnitt 8 der IEEE 1394 Norm beschreibt, dass
eine Durchführungsstation
eine Anzahl Register (CSR) hat. Der Inhalt einiger dieser Register
kann in Reaktion auf Beantragungspakete von allen Beantragungsstationen
modifiziert werden.
-
Zur
Vermeidung von Fehlern sollte die Beantragungsstation, die ein Beantragungspaket
sendet, imstande sein, auf zuverlässige Weise zu bestimmen, ob
der Befehl wirklich durchgeführt
worden ist, insbesondere, wenn der Effekt einer wiederholten Durchführung des
Befehls von dem Effekt eines einzigen Befehls abweicht (beispielsweise
im Fall eines Befehls: "Fernsehkanalnummer
erhöhen" oder eines Befehls "Kapazität reservieren"). Wenn die Durchführungsstation
ein Zustandsregister enthält,
das von der Durchführung
des Befehls betroffen ist und das von einem Befehl von der Beantragungsstation
gelesen werden kann, ist es im Grunde möglich, zu bestimmen, ob der
Befehl durchgeführt
worden ist, indem der Inhalt des Zustandsregisters überprüft wird. Überprüfung des
Inhaltes des Zustandsregisters zum Detektieren der Durchführung wirkt
aber nicht zuverlässig,
wenn das Bussystem mehr als nur eine Beantragungsstation enthält, die
ein Beantragungspaket mit einem Befehl senden kann, der dasselbe
Zustandsregister betrifft.
-
In
1394 sendet die Durchführungsstation nach
der Durchführung
eines Befehls ein Antwortpaket zu derjenigen Beantragungsstation
zurück,
die das Beantragungspaket herausgab, worauf der Befehl durchgeführt wurde.
Dies ermöglicht
es, dass die Beantragungsstation ermittelt, ob der Befehl durchgeführt worden
ist, es wirkt aber nicht, wenn die Beantragungsstation das Antwortpaket
nicht empfängt.
-
Es
ist nun u. a. eine Aufgabe der vorliegenden Erfindung eine zuverlässigere
Art und Weise zu schaffen um zu ermitteln, ob der Befehl auch wirklich durchgeführt worden
ist.
-
Nach
der vorliegenden Erfindung wird das Kommunikationsbussystem nach
der vorliegenden Erfindung gekennzeichnet durch den kennzeichnenden
Teil des Anspruchs 1. Durch Auslesung der Befehlsdurchführungsinformation
kann jede einzelne Beantragungsstation überprüfen, ob ein von ihr beantragter
Befehl durchgeführt
worden ist. Eine spätere
Durchführung
beantragter Befehle durch andere Beantragungsstationen beeinträchtigt nicht
die Befehlsdurchführungsinformation
für die
betreffende Beantragungsstation und deswegen wird die Zuverlässigkeit
der Überprüfung nicht
beeinträchtigt.
-
Das
Kommunikationsbussystem nach der vorliegenden Erfindung hat eine
Ausführungsform, wie
diese in Anspruch 6 beschrieben worden ist. Bei dieser Ausführungsform
kann eine bestimmte Beantragungsstation mehrere Beantragungspakete,
die Durchführung
verschiedener Befehlstypen beantragen ausgeben und überprüfen, ob
die entsprechenden Befehle durchgeführt worden sind, nachdem alle Beantragungspakete
ausgegeben worden sind. Dies bedeutet, dass die Beantragungspakete
schnell nacheinander als ein kohärenter
Vorgang ausgegeben werden können,
ohne Unterbrechung zur Überprüfung. In
einem 1394 System beeinträchtigt
jeder Befehlstyp beispielsweise ein anderes CSR und das Kommunikationsbussystem
behält
Information für jede
betreffende Beantragungsstation über
die zuletzt durchgeführte
Modifikation der CSR, welche diese betreffende Beantragungsstation
beantragt hat.
-
Es
können
verschiedene Formen von Befehlsdurchführungsinformation gespeichert
werden. Wenn die Beantragungsstation in jedem Paket eine betreffende
Paketidentifikation enthält,
kann die gespeicherte Befehlsdurchführungsinformation diese Paketidentifikation
enthalten. Dies ermöglicht
es, die Durchführung
jedes Befehls zu jeder Zeit zu überprüfen. Die
gespeicherte Befehlsdurchführungsinformation
kann Information über
den Zustand der Durchführungsstation
unmittelbar nach der Durchführung oder
Information über
die Ergebnisse der Durchführung
enthalten. Dies ermöglicht
es, dass die Beantragungsstation die Durchführung des Befehls so detailliert
wie nur erwünscht,
beispielsweise detaillierter als in einer Standardantwort von der
Durchführungsstation,
analysieren kann. Diese Befehlsdurchführungsinformation kann für alle Beantragungspakete,
die von der Durchführungsstation
empfangen werden, gespeichert gehalten werden, oder sie kann für eine vorbestimmte
Anzahl Beantragungspakete gespeichert gehalten werden, für welche
die Befehle erste gerade durchgeführt worden sind. Auf diese
Weise können ältere Befehle
analysiert werden.
-
Die
Befehlsdurchführungsinformation
kann verschiedenartig gespeichert werden. Jeder Beantragungsstation
kann ein betreffendes vorbestimmtes Speichergebiet in der Durchführungsstation
zugeordnet werden. Wenn ein Befehl in Reaktion auf ein Beantragungspaket
von einer bestimmten Beantragungsstation durchgeführt wird,
kann die Durchführungsstation
die Befehlsdurchführungsinformation
für diese
Durchführung
verwenden um Befehlsdurchführungsinformation
zu überschreiben,
die in dem Speichergebiet gespeichert ist, das der betreffenden
Beantragungsstation zugeordnet wurde. Auf diese Weise enthält das Speichergebiet
immer die Befehlsdurchführungsinformation
für den
jüngsten
durchgeführten
Befehl für
diese betreffende Station (oder Initialisierungsinformation, gespeichert
durch die Durchführungsstation
vor dem Empfang eines Beantragungspaketes). Das jeder betreffenden
Station zugeordnete Speichergebiet kann in Speicherteilgebiete für verschiedene
Befehlstypen aufgeteilt sein, wobei die Durchführungsstation nur das Speicherteilgebiet
für den
Befehl, der durchgeführt
wird, überschreibt.
-
In
einer bevorzugten Ausführungsform
wird nur ein einziges logisches Bit je Befehlstyp für jede Beantragungsstation
gespeichert. Wenn die Durchführungsstation
in Reaktion auf den Beantragungspaket von einer bestimmten Beantragungsstation
erfolgreich einen Befehl durchgeführt hat, setzt die Durchführungsstation
das logische Bit für
diese betreffende Beantragungsstation (und für den Befehlstyp, wenn mehr
als nur ein Befehlstyp aufgezeichnet wird). In diesem Fall muss
die Durchführungsstation auch
imstande sein, das logische Bit zurückzusetzen, vorzugsweise in
Reaktion auf ein Signal von der betreffenden Beantragungsstation.
In dem 1394 System kann dieses Signal beispielsweise erzeugt werden,
wenn die betreffende Beantragungsstation das CSR ausliest, dessen
Modifikation durch das logische Bit aufgezeichnet wird.
-
Das
Auslesen der Befehlsdurchführungsinformation
wird vorzugsweise durch ein Auslesepaket ausgelöst, das von der Beantragungsstation über die Busverbindung
der Durchführungsstation
zugeführt worden
ist. In Reaktion auf dieses Auslesepaket ermittelt die Durchführungsstation,
von welcher Beantragungsstation das Auslesepaket geliefert worden ist,
liest die Befehlsdurchführungsinformation,
die für diese
Beantragungsstation gespeichert worden ist und sendet unter Ansteuerung
dieser Befehlssteuerinformation über
den Verbindungsbus der Beantragungsstation ein Zustandspaket zu.
-
Vorzugsweise
wird die Speicherung von Befehlsdurchführungsinformation kombiniert
mit der Übertragung
von Antwortpaketen durch die Durchführungseinheit. Dies bietet
der Beantragungsstation die Möglichkeit,
bei kritischer Durchführung
von Befehlen zu überprüfen, wenn
kein Antwortpaket empfangen wird.
-
Diese
und andere vorteilhafte Aspekte der vorliegenden Erfindung sind
auf eine nicht begrenzende Weise unter Verwendung einer einzigen
Figur, die ein Kommunikationsbussystem nach der vorliegenden Erfindung
zeigt, beschrieben.
-
Die
Figur zeigt ein Kommunikationsbussystem nach der vorliegenden Erfindung.
Das Kommunikationsbussystem enthält
eine Durchführungsstation B,
Beantragungsstationen A, 14 und einen Verbindungsbus 12.
Die Durchführungsstation
B enthält eine
Paketempfangs/Interpretationseinheit 102, eine Befehlsdurchführungseinheit 104,
einen Befehlsdurchführungsinformationsspeicher 106 und
eine Paketerzeugungs/Sendeeinheit 108.
-
Das
Kommunikationsbussystem benutzt beispielsweise das in der IEEE 1394
Norm spezifizierte Protokoll. Der IEEE-1394 serielle Hochgeschwindigkeitsbus
benutzt einen Transaktionsmechanismus, der es ermöglicht,
dass jede Anordnung (Station) A, B, 14 am Bus 12 automatisch
Lese-Modifizier-Schreibvorgänge
au jeder beliebigen Speicherstelle schreiben, lesen oder durchführen kann
oder in jeder anderen Station A, B, 14 steuern und den
Zustand registrieren kann. Es gibt keinen Unterschied zwischen CSRn
und dem Speicher in 1394, da CSR speicherorientiert sind.
-
Um
die Station eine Transaktion zu der Station B durchführen zu
lassen, ist die typische Sequenz, dass die Station A der Station
B ein Beantragungspaket zusendet, dass B eine Empfangsbestätigung zurücksendet,
danach die beantragte Funktion durchführt (nimmt Zeit), dann ein
Antwortpaket mit dem Funktionsergebnis oder mit einem Zustand über die Durchführung sendet,
wonach A eine Empfangsbestätigung
für das
Antwortpaket zu B zurücksendet.
-
Die
Beantragungs- und Antwortpakete enthalten Identifikationen des Senders
(A in dem Antrag, B in der Antwort), des bestimmten Empfängers (B
in dem Antrag, A in der Antwort), eine Folgenummer für diese
Transaktion von A nach B und Daten (Funktion, Ergebnisse, Zustand,
usw.). Diese Pakete werden ebenfalls durch einen CRC Fehlerdetektionscode
geschützt,
wodurch der Empfänger
Paketverfälschung detektieren
kann.
-
Die
Bestätigungspakete
enthalten keinen der oben genannten Kennzeichen, nur die Zustandsinformation
und einen sehr einfachen Fehlerdetektionscode.
-
Es
wurde ein Problem entdeckt bei Transaktionen, die CSR ändern, wenn
die Pakete (Antrag/Antwort/Bestätigung)
verfälscht
oder aus irgendeinem Grund an dem Bus verloren gehen können. Dieses
Problem führt
zu Inkonsistenz in der Information über den Zustand des CSRs (und
der Nebeneffekte desselben) für
den Beantragungsteller (A) und den Beantworter (B).
-
Beispiel 1:
-
Die
Station enthält
eine allgemeinen Busquelle, die verfügbare Bandbreite für isochrone
Datenübertragung
angibt. Die Station A möchte
einen Teil dieser Bandbreite zuordnen und sendet ein Beantragungspaket
zu B, das eine sog. Vergleich-Tauasch-Verriegelungsfunktion enthält, die
versucht, den Betrag an verfügbarer
Bandbreite um den beantragten Betrag zu reduzieren. Ein Antwortpaket,
das B zu A zurücksendet,
gibt an, ob die Zuordnung erfolgreich war und folglich, ob ggf.
A nun die Bandbreite besitzt und diese benutzen kann. Es wird nun
vorausgesetzt, dass der Antrag ohne Fehler bei B eintrifft und durchgeführ wird
und erfolgreich ist (Bandbreite wird A zugeordnet). Das Antwortpaket
wird zu A zurückgesendet,
erreicht sie aber nie, sogar nicht nach etwaiger Neuübertragung
durch B. A weiß nicht,
ob sie Bandbreite erhalten hat und wird nie die Zuordnung aufheben:
der beantragte Betrag ist einfach für isochrone Daten nicht länger verfügbar.
-
Beispiel 2:
-
Station
B ist ein Fernsehgerät,
das ein CSR implementiert, das, wenn dorthin geschrieben wird, den
nächsten
Kanal selektiert. Wenn A eine Schreibtransaktion zu B sendet um
den nächsten
Kanal zu schalten, aber wird nie klug daraus, ob der Befehl auch
wirklich durchgeführt
worden ist, denn sie könnte
entscheiden den Befehl zu wiederholen, wenn vorausgesetzt wird,
dass etwas daneben gegangen ist. Es ist möglich, dass das Fernsehgerät B eine
Funktion "Kanal
aufwärts" zweimal durchgeführ hat und nun
den falschen Kanal zeigt.
-
Transaktionen,
die ein CSR nicht ändern
und die überhaupt
keine Nebeneffekte haben, leiden nicht an diesem Problem, da diese
auf sichere Weise neu versucht werden können, wenn der Beantragungsteller
erwartet, dass etwas daneben gegangen ist. Transaktionen, die CSR ändern und/oder
Nebeneffekte haben, können
für einige
Anord nungen (Beispiel 2) zu unerwünschten Ergebnissen führen oder sogar
zu einem Fehlverhalten des ganzen Busses (Beispiel 1).
-
Das
Problem wird vorwiegend verursacht durch die Tatsache, dass die
einzige Möglichkeit
für einen
Beantragungsteller die Ergebnisse seines Beantragungs herauszufinden,
ist, dass er die Antwort erhält.
Wenn die Antwort verloren gegangen ist, gibt es keine Möglichkeit,
die Information nachher von der antwortenden Station abzufragen.
Das Auslesen des CSRs, von dem angenommen wurde, dass es geändert ist,
ist nicht eine Lösung,
weil andere Stationen es inzwischen haben ändern können, oder das Auslesen kann
Nebeneffekte haben, die unerwünscht sind.
-
Durch
Fehler im Netzwerk gibt es nach der Transaktion die nachfolgenden
Zustände:
S1:
die Transaktion ist durchgeführt
und der Beantragungsteller weiß es.
S2:
die Transaktion ist nicht durchgeführt und der Beantragungsteller
weiß es.
S3:
die Transaktion ist durchgeführt
aber der Beantragungsteller weiß es
nicht.
S4: die Transaktion ist nicht durchgeführt aber
der Beantragungsteller weiß es
nicht.
-
Der
Ausdruck "durchgeführ" bedeutet in dem vorliegenden
Fall, dass die Funktion entsprechend der Transaktion durchgeführt wurde,
ungeachtet, ob dies zu einer Änderung
des CSR-Wertes geführt
hat.
-
Für den Beantragungsteller
sind S3 und S4 nicht unterscheidbar: er weiß ganz einfach nicht, ob der
Antrag durchgeführt
wurde. Dies sind die Problemfälle
wenn die Transaktion von einem Typ war, der zu einer Änderung
in dem CSR-Wert hätte
führen können oder
wenn es Nebeneffekte gegeben hat. S1 und S2 können unmittelbar von dem Beantragungsteller
behandelt werden und bilden kein Problem.
-
Die
Lösung
dieses Problems ist der folgende Konzept:
Jede beliebige Durchführungsstation,
die ein CSR implementiert, das vor dem oben genannten Problem geschützt werden
soll, speichert vorzugsweise das Ergebnis oder den Zustand von Transaktionen,
die empfangen und durchgeführt
wurden (ob erfolgreich oder nicht) von einer externen Station, so
dass sie nachher von dieser Station abgefragt werden können. Dazu
enthält
die Durchführungsstation 10 einen Befehlsdurchführungsinformationsspeicher 106.
Im Betrieb empfängt
die Paketempfangs/Übersetzungseinheit 102 Pakete
von dem Bus 12 und interpretiert sie wie folgt. Zunächst bestimmt
die Ein heit 102 ob das Paket die Durchführungsstation 10 als
bezeichneter Empfänger
spezifiziert. Sollt dies der Fall sein, so extrahiert die Einheit 102 Information
aus dem Paket, die bestimmt, welcher Befehl durchgeführt werden
soll und liefert diese Information zu der Befehlsdurchführungseinheit 104,
die den Befehl durchführt. Ein
Ergebnis der Durchführung
wird dem Befehlsdurchführungsinformationsspeicher 106 zugeführt und
darin gepeichert, wenn die Einheit 102 signalisiert, dass
der Befehl durchgeführt
worden ist.
-
Die
Durchführungsstation 10 definiert
vorzugsweise ein "Error
Status Register" (ESR)
in dem CSR Raum, auf den mit einer LeseBeantragungstransaktion von
jeder Beantragungsstation zugegriffen werden kann und auf Information
in dem Befehlsdurchführungsspeicher 106 zugreift.
Eine derartige Station kann auf diese Weise den Zustand eine der vorhergehend
beantragten Transaktionen auslesen. Das Auslesen des ESRs an sich
hat keine Nebeneffekte. Der Zustand der Beantragungsstation kann
dadurch gelöscht
werden, dass die Beantragungsstation dem ESR (ungeachtet der geschriebenen
Daten) unter Anwendung einer SchreibBeantragungstransaktion schreibt.
Eine Beantragungsstation kann unter Anwendung dieses Mechanismus
nur Zustandsinformation über
die eigenen Transaktionen löschen.
-
In
dem 1394 System ermöglicht
die Tatsache, dass jeder Antrag die Bezeichnung der Beantragungsstation
enthält,
dass ein Responder einer derartigen Transaktion die Zustandsinformation
zusammen mit einem Kennzeichen, das einzigartig die Transaktion
identifiziert (d.h. das Adresskennzeichen der Beantragungsstation
und die Transaktionsfolgenummer). Diese Information kann auch in
dem Antwortpaket zurückgesendet
werden.
-
Der
Unterschied zwischen den oben genannten Zuständen S3 und S4 ist an der antwortenden
Station verfügbar
und erinnert dort für
eine spätere
Suche durch den Beantragungsteller im Falle es in einem dieser Zustände endet.
-
Da
alle Stationen an dem Bus unabhängig voneinander
Transaktionen zu einem einzigen CSR in einer bestimmten Station
durchführen
können, muss
sich diese Station den Zustand von Transaktionen für jede Station
erinnern können.
Wenn eine Station später
das ESR liest, wird sie nur den Zustand für die eigenen Transaktionen
erhalten, nicht von denen, die von anderen Stationen beantragt wurden.
-
Ausführungsformen
-
A. Speicherung des Zustandes
(wie oft zu speichern)
-
- A1. In der meist allgemeinen Implementierung
erinnert sich die Station alle einzigartig identifizierbaren Transaktionen
aller Stationen. In IEEE 1394 ist eine Stationsadresse 16 Bits und
die Transaktionsfolgenummer ist 6 Bits. Dies führt zu einer "schlimmsten-Fall"-Situation, in der
2^22 Zustandswerte gespeichert werden sollen.
- A2. Es ist nicht notwendig eine derartige Speichermöglichkeit
auch wirklich zu implementieren. Nut Daten für wirkliche Transaktionen sollen
gespeichert werden, was, wie erwartet, viel weniger ist (Indikation:
bis einige Tausend für "very high end" Implementierungen).
- A3. Eine einfachere Methode ist, nur den Zustand der letzten
je Station durchgeführten
Transaktion zu speichern und dies nur für Stationen an dem Ortsbus
zu unterstützen,
nicht aber für
andere Stationen, die durch Brücken
verbunden sind. Dies reduziert die Speicheranforderungen auf nicht
mehr als 62 Stellen.
-
B. Darstellung des Zustandes
(was muss gespeichert werden)
-
- B1. Die meist allgemeine Implementierung würde den
ganzen Ergebniszustand einer Transaktion speichern, d.h. wenn das
ursprüngliche
Beantragungspaket empfangen wurde, dann ist Information über die
nachfolgenden Ereignisse verfügbar: durchgeführt oder
nicht, warum nicht durchgeführt,
Fehler bei der Lieferung eines Antwortpakets, usw. Für IEEE 1394
würde es
ausreichen, den ursprünglichen
Antwortcode aufzuzeichnen, der in einem Antwortpaket zu dem Beantragungsteller
geliefert werden sollte, zusammen mit zusätzlicher Information, wesentlich
für den
Beantragungsteller um eine Entscheidung zu treffen: beispielsweise
CSR modifiziert in einer Verriegelungstransaktion (nicht in dem
Antwortcode dargestellt) oder Nebeneffekt des Beantragungs auf CSR
durchgeführt.
- B2. Eine einfachere Implementierung kann ausreichen durch Aufzeichnung
nur der Information über
den Konzeptzustand des Responders, wenn er startet, ein Antwortpaket
zurückzusenden
(S3 oder S4, wie oben angegeben), und nichts anderes. Dies kostet
nur 1 Speicherbit je Transaktion. Insbesondere in Kombination mit
Option A3 sind die Speicheranforderungen minimal. Da aber das ursprüngliche
Merkmal, das einzigartig die Transaktion identifiziert, nicht erinnert
wird, ist es nicht klar, ob der wirklich erinnerte Zustand für eine Station
X zu dem letzten übertragenen
Beantragungspaket der Station X gehört (wenn dieses Paket verloren
gegangen ist, dann wird der Zustand dennoch das Ergebnis des vorher
empfangenen Beantragungs von der Station X reflektieren). Für diese
Implementierung muss der Fehlerzustand zu einem sicheren Wert gelöscht werden (ent sprechend
dem Konzeptzustand S4) bevor die unsichere neue Transaktion versucht
wird (nur wenn es noch nicht in diesem Zustand ist). Eine Art und
Weise dies mit minimalen Kosten zu tun, ist zu definieren, dass
jede Transaktion ohne Nebeneffekte auf das geschützte CSR zu einer Änderung
des aufgezeichneten Zustandes zu S4 führt, was als "keine Nebeneffekte
aus der letzten empfangenen Transaktion". In IEEE 1394 würde eine ausgelesene Transaktion
typischerweise keine Nebeneffekte haben. Gleichzeitig ist es die Standartart
einen der Datenwerte, erforderlich für eine Vergleiche-Tausche-Verriegelungstransaktion,
zu erhalten. Dies ist was diese Mechanismen sehr geeignet macht
für Implementierung
in IEEE 1394 zum Schützen
dieser Art von CSR.
-
C. Zugriff auf den Zustand
(wie soll es verfügbar
gemacht werden)
-
Implementierungen
um den Zustand verfügbar
zu machen kann jede beliebige Form haben, soll aber standardisiert
werden (das Verfahren darauf zuzugreifen, das Format, in dem die
Information zurückkehrt
und möglicherweise
die Offsetadresse der Station, assoziiert mit jedem ESR).
- C1. Die meist universelle Lösung ist, wobei jede Station
den Transaktionszustand jeder beliebigen Station herausfinden kann,
und zwar unter Verwendung von Auslesetransaktionen (ohne Nebeneffekte)
auf ein speziell eingeführtes
Zustandsregister, das als "Error
Status Register" (ESRR)
Fehlerzustandsregister bezeichnet wird, das an sich ein CSR ist,
wie in der IEEE 1212 und der IEEE 1394 Architektur definiert. Daten
in der ausgelesenen Transaktion müssen verwendet werden zum Indizieren
in dem Speicher zum Zugreifen auf den erwünschten Zustand. Dies ist nicht
leicht zu implementieren mit den aktuellen 1394 Transaktionen.
- C2. Da C1 unnötig
komplex ist, ist es besser Lösungen
zu erforschen, wobei jede beliebige Station nur auf die Ergebnisse
der eigenen Transaktionen zugreifen kann. Dadurch, dass eine Lesetransaktion
in dem ESR durchgeführt
wird, kann der Responder die Stationsadresse des Senders (Beantragungstellers)
in dem Transaktionspaket verwenden um den richtigen Zustandswert
zu selektieren und diesen als gelesene Antwort zurückzusenden.
Information
darüber,
von welcher Transaktion aus der Vergangenheit der Zustand zurückgesendet werden
soll kann nicht in dem Lesetransaktionspaket eingeschlossen sein,
es sei denn, dass das ESR eine Reihe von Adressen hat und die Adresse
als Index verwendet wird. Dies ist nicht erwünscht, da es viele ESR geben
kann, die je nur ein anderes CSR (Adresse) schützen. Eine Option ist, den
Zustand für
alle (bis zu 63) vorhergehen den Transaktionen zurückzusenden
und den Beantragungsteller die richtige selektieren zu lassen.
- C3. Eine weitere Vereinfachung ist in Kombination mit A3 möglich. Wenn
nur der Zustand der letzten Transaktion gespeichert wird, wird das
in C2 genannte Problem vermieden und eine einzige Adresse ESR reicht.
Paketgrößen und
Gemeinkosten werden in dem Fall minimal sein.
- C4. In Kombination mit B2 und A3 wäre eine sehr einfache Implementierung
zum Implementieren des ESRs als ein 63 Bit Register, wobei das Bit
k den Zustand der letzten von der örtlichen Station durchgeführten Transaktion
darstellt. Eine logische 0 könnte
benutzt werden um anzugeben "kein
Nebeneffekt/nicht durchgeführt" und eine logische
1 um anzugeben "CSR
modifiziert/Nebeneffekt".
Dies ist der einfachste und wahrscheinlich der aussichtsreichster
Kandidat zur Implementierung.