Spaziatura in uscita

Se l'applicazione dispone di risorse sufficienti per gestire i dati in uscita quanto la rete può fornirla (ad esempio, una schermata) o se un protocollo di livello superiore (ad esempio, la modalità richiesta immediata) vincola il flusso di dati, l'applicazione non deve essere coinvolta nella velocità ed è possibile che il nodo locale gestisca la velocità in uscita in modo trasparente.

Tuttavia, alcuni tipi di applicazioni possono richiedere il coinvolgimento nel ritmo in uscita. Se l'applicazione dispone di risorse limitate (ad esempio, una stampante), l'applicazione deve specificare l'opzione di velocità dell'applicazione nel blocco di controllo delle informazioni di connessione (CICB) nella risposta OK Open(PLU). Per altre informazioni, vedere Apertura della connessione PLU. L'applicazione deve anche fornire al nodo locale informazioni sullo stato di queste risorse inizialmente nella risposta OK Open(PLU) e periodicamente usando i messaggi Status-Resource .

Per facilitare l'applicazione nel calcolo del campo di credito iniziale nella risposta OPEN(PLU) OK, il nodo locale fornisce le dimensioni della finestra di velocità e le dimensioni massime richieste/unità di risposta (UR) primarie e secondarie nella richiesta Open(PLU). Il credito iniziale deve essere pari almeno alla dimensione della finestra di pacing da primaria a secondaria. In caso contrario, bind verrà rifiutato e l'applicazione verrà inviato un messaggio di conferma dell'errore Open(PLU). Il nodo locale inserisce un valore di credito iniziale suggerito di un valore superiore alla finestra di inserimento (per evitare situazioni di arresto/ avvio).

Si noti che il nodo locale rifiuterà anche BIND se l'applicazione specifica che deve essere coinvolta nel ritmo (di qualsiasi credito iniziale), ma BIND specifica che non è presente alcun ritmo in uscita.

Solo le richieste FMD (Function Management Data) fanno parte dello schema di credito, pertanto l'applicazione deve mantenere lo spazio all'interno del buffer per una richiesta di controllo dello stato per UR oltre al numero di UR specificato dal conteggio dei crediti iniziale. Un messaggio di controllo dello stato richiede 36 byte.

Ogni unità di credito che l'applicazione recapita al nodo locale consente al nodo locale di assegnare all'applicazione una singola UR (o un singolo blocco se viene usata la suddivisione in blocchi). Si noti che se l'applicazione riceve segmenti, questo può corrispondere a diversi messaggi DATAFMI . L'applicazione può contare le UR ai fini del controllo del flusso in uscita usando i flag BBIU (Begin Basic Information Unit) e EBIU (End Basic Information Unit).

L'applicazione deve mantenere un conteggio usato dal credito, che deve segnalare al nodo locale nei messaggi Status-Resource . L'applicazione deve eseguire le azioni seguenti:

• Durante l'elaborazione (non ricevente) messaggi DATAFMI con set EBIU (corrispondente alle richieste FMD), incrementare il conteggio utilizzato dal credito di uno.

• Durante l'elaborazione dei messaggi Status-Control e di tutti gli altri messaggi dal nodo locale, non incrementare il conteggio dei crediti usati.

• Segnalare periodicamente il conteggio corrente del credito usato in un messaggio Status-Resource .

• Segnalare il conteggio utilizzato dal credito quando il buffer diventa vuoto (indipendentemente dall'ultimo messaggio elaborato), a meno che il conteggio dei crediti usati non sia zero.

• Quando il conteggio dei crediti usati viene segnalato al nodo locale, reimpostarlo su zero.

  La frequenza con cui l'applicazione fornisce messaggi Status-Resource non è progettata. Tuttavia, il nodo locale invierà all'applicazione solo il numero di messaggi dati ricevuti come credito. Quando il conteggio del credito usato dall'applicazione raggiunge il valore di credito iniziale, il nodo locale non invierà altri dati. L'applicazione deve tentare di inviare un messaggio Status-Resource prima che ciò accada, perché se il nodo locale non può inviare un messaggio Dati all'applicazione e l'host sta ancora inviando richieste, il nodo locale potrebbe non essere in grado di inviare una risposta di ritmo all'host quando necessario, con conseguente riduzione delle prestazioni.

  Se la finestra di pacing è piccola, ad esempio una o due, l'applicazione deve inviare una risorsa di stato dopo l'elaborazione di ogni messaggio DATAFMI per consentire al nodo locale di inviare la risposta appropriata.

  Nella figura seguente viene illustrato il ritmo in uscita gestito dal nodo locale quando l'applicazione non è coinvolta (APPLPAC = 0x00). Si presuppone che la finestra di ritmo sia due.

  
  Ritmo in uscita per la gestione dei nodi locali

  La figura seguente illustra il nodo locale e l'applicazione che gestisce la pacing in uscita con la finestra di pacing in uscita presupponendo che sia due e il credito iniziale dal nodo locale all'applicazione si presuppone che sia quattro. Si noti che il nodo locale può inviare una risposta di pacing isolata (IPR) all'host per ottenere un'altra finestra piena di dati non appena l'applicazione dispone di credito sufficiente per il resto della finestra presente e la finestra successiva.

  
  Pacing in uscita per il nodo locale e l'applicazione

Vedere anche

Apertura della connessione PLU
Sessione PLU
Concatenamento in uscita
Concatenamento in ingresso
Consegna segmenti
Parentesi
Direzione
Spaziatura e suddivisione in blocchi
Conferma e rifiuto dei dati]
Arresto e disattivazione
Ripristino
Terminazione avviata dall'applicazione
LUSTAT]
Dati di monitoraggio del tempo di risposta