Ausgehendes Pacing

Wenn die Anwendung über genügend Ressourcen verfügt, um ausgehende Daten so schnell zu verarbeiten, wie das Netzwerk sie bereitstellen kann (wie beispielsweise ein Display), oder wenn ein Protokoll auf höherer Ebene (wie der Sofortanforderungsmodus) den Datenfluss einschränkt, muss die Anwendung nicht am Tempo beteiligt sein, und es ist möglich, dass der lokale Knoten das ausgehende Tempo transparenterweise verarbeiten kann.

Bestimmte Arten von Anwendungen erfordern jedoch möglicherweise eine Einbindung in eine externe Steuerung. Wenn die Anwendung über begrenzte Ressourcen verfügt (z. B. einen Drucker), sollte die Anwendung die Anwendungs-Pacing-Option im Verbindungsinformationssteuerungsblock (CICB) auf der Open(PLU)-OK-Antwort angeben. (Weitere Informationen finden Sie unter Öffnen der PLU-Verbindung.) Die Anwendung sollte auch den lokalen Knoten mit Informationen zum Status dieser Ressourcen zunächst in der Open(PLU)-OK-Antwort und regelmäßig mithilfe von Statusressourcenmeldungen bereitstellen.

Um die Anwendung bei der Berechnung des anfänglichen Kreditfelds in der Open(PLU) OK Response zu unterstützen, liefert der lokale Knoten die Pacingfenstergrößen sowie die Größen der primären und sekundären maximalen Anforderungs-/Antworteinheit (RU) in der Open(PLU) Request. Die anfängliche Gutschrift muss mindestens so groß sein wie die Fenstergröße des primären zum sekundären Taktfensters. Andernfalls wird der BIND abgelehnt, und die Anwendung wird eine Open(PLU)-Fehlermeldung erhalten. Der lokale Knoten füllt einen vorgeschlagenen Anfangskreditwert aus, der um eins mehr als das Pacing-Fenster beträgt, um Stop-Start-Situationen zu vermeiden.

Beachten Sie, dass der lokale Knoten auch das BIND zurückweist, wenn die Anwendung angibt, dass sie am Pacing in Bezug auf den anfänglichen Kredit beteiligt sein muss, aber das BIND angibt, dass es kein ausgehendes Pacing gibt.

Nur FmD-Anforderungen (Function Management Data, Funktionsverwaltungsdaten) sind Teil des Kreditschemas, sodass die Anwendung platz im Puffer für eine Statussteuerungsanforderung pro RU zusätzlich zur Anzahl der RUs beibehalten muss, die durch die anfängliche Kreditanzahl angegeben werden. (Eine Statussteuerungsmeldung dauert 36 Bytes.)

Jede Krediteinheit, die die Anwendung an den lokalen Knoten übermittelt, ermöglicht es dem lokalen Knoten, der Anwendung eine einzelne RU (oder einen einzelnen Block zuzuweisen, wenn Blöcke verwendet werden). Beachten Sie, dass dies möglicherweise mehreren DATAFMI-Nachrichten entspricht, wenn die Anwendung Segmente empfängt. Die Anwendung kann RUs für den Zweck der Ausgehenden Flusssteuerung zählen, indem sie die Kennzeichnungen für die Basisinformationseinheit (Begin Basic Information Unit, BBIU) und die Endgrundinformationseinheit (EBIU) verwenden.

Die Anwendung sollte eine verwendete Kreditzahl verwalten, die sie auf Status-Ressourcen-Meldungen an den lokalen Knoten melden soll. Die Anwendung muss die folgenden Aktionen ausführen:

• Bei der Verarbeitung (nicht empfangender) DATAFMI-Nachrichten mit EBIU-Satz (entsprechend FMD-Anforderungen) erhöhen Sie die anzahl der verwendeten Kreditwerte um eine.

• Bei der Verarbeitung von Statussteuerungsmeldungen und allen anderen Nachrichten vom lokalen Knoten erhöhen Sie nicht den Zähler für verwendete Kredite.

• Berichten Sie regelmäßig über die aktuelle Zahl der genutzten Gutschriften in einer Nachricht vom Typ Status-Resource.

• Melden Sie die Anzahl der genutzten Guthaben, wenn der Puffer leer wird (unabhängig von der zuletzt verarbeiteten Nachricht), es sei denn, die Anzahl der genutzten Guthaben ist null.

• Wenn die Anzahl der verwendeten Gutschriften an den lokalen Knoten gemeldet wird, setzen Sie sie auf Null zurück.

  Die Häufigkeit, mit der die Anwendung Statusressourcenmeldungen bereitstellt, wird nicht erstellt. Der lokale Knoten sendet an die Anwendung jedoch nur so viele Datennachrichten, wie er eine Gutschrift dafür erhalten hat. Wenn die von der Anwendung verwendete Kreditsumme den ursprünglichen Kreditwert erreicht, sendet der lokale Knoten keine weiteren Daten mehr. Die Anwendung sollte versuchen, eine Statusressource-Nachricht zu senden, bevor dies geschieht. Wenn der lokale Knoten keine Datennachricht an die Anwendung senden kann und der Host weiterhin Anforderungen sendet, kann der lokale Knoten möglicherweise keine Pacingantwort an den Host senden, wenn erforderlich, mit einer konsequenten Beeinträchtigung der Leistung.

  Wenn das Pacing-Fenster klein ist, z. B. ein oder zwei, sollte die Anwendung nach der Verarbeitung jeder DATAFMI-Nachricht eine Statusressource senden, um dem lokalen Knoten das Senden der geeigneten Pacing-Antwort zu ermöglichen.

  Die folgende Abbildung zeigt den lokalen Knoten, der ausgehende Pacing verarbeitet, wenn die Anwendung nicht beteiligt ist (APPLPAC = 0x00). Das Periodenfenster wird als zwei angenommen.

  
  Lokaler Knoten, der das Ausgehend-Pacing verwaltet

  Die folgende Abbildung zeigt den lokalen Knoten und die Anwendung, die ausgehendes Pacing mit dem ausgehenden Pacing-Fenster verarbeitet, als zwei und die anfängliche Gutschrift vom lokalen Knoten an die Anwendung als vier angenommen. Beachten Sie, dass der lokale Knoten eine isolierte Pacing-Antwort (IPR) an den Host senden kann, um ein weiteres Fenster voller Daten abzurufen, sobald die Anwendung über ausreichende Gutschrift für den Rest des aktuellen Fensters und das nächste Fenster verfügt.

  
  Lokaler Knoten und Anwendungshandhabung für ausgehendes Taktverhalten

Siehe auch

Öffnen der PLU-Verbindung
PLU-Sitzung
Ausgehende Verkettung
Eingehende Verkettung
Segmentzustellung
Brackets
Richtung
Temporisierung und Chunking
Bestätigung und Ablehnung von Daten]
Herunterfahren und Beruhigen
Wiederherstellung
Anwendungsinitiierte Beendigung
LUSTATs]
Antwortzeitüberwachungsdaten