Regolazione in uscita

Se l'applicazione dispone di risorse sufficienti per gestire i dati in uscita il più velocemente possibile che la rete possa 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 nei processi di pacing in uscita. Se l'applicazione dispone di risorse limitate(ad esempio, una stampante), l'applicazione deve specificare l'opzione 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 inoltre fornire al nodo locale informazioni sullo stato di queste risorse inizialmente nella risposta OPEN(PLU) OK 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 della richiesta/unità di risposta massima primaria e secondaria (UR) nella richiesta Open(PLU). Il credito iniziale deve essere pari almeno alla dimensione della finestra di scorrimento 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'unità superiore alla finestra di pacing (per cercare di evitare situazioni di arresto/avvio).

Si noti che il nodo locale rifiuterà anche l'associazione se l'applicazione specifica che deve essere coinvolta nel controllo del flusso (di qualsiasi credito iniziale), ma l'associazione specifica che non è presente alcun controllo del flusso verso l'esterno.

Solo le richieste di dati di gestione delle funzioni (FMD) 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 del credito 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 End Basic Information Unit (EBIU).

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

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

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

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

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

• Quando il conteggio dei crediti usati viene segnalato al nodo locale, reimpostalo 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 Di dati per cui ha ricevuto il 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 pacing all'host quando necessario, con conseguente riduzione delle prestazioni.

  Se la finestra di scorrimento è 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.

  La figura seguente mostra il nodo locale che gestisce la velocità in uscita quando l'applicazione non è coinvolta (APPLPAC = 0x00). Si assume che la finestra di temporizzazione sia pari a due.

  
  Gestione del ritmo di uscita dei nodi locali

  La figura seguente illustra il nodo locale e l'applicazione che gestisce l'invio dei dati in uscita, con la finestra di pacing in uscita posta a due e il credito iniziale dal nodo locale all'applicazione impostato su quattro. Si noti che il nodo locale può inviare all'host una risposta di pacing isolata per ottenere un'altra finestra piena di dati non appena l'applicazione ha un credito sufficiente per il resto della finestra presente e la finestra successiva.

  
  Gestione della velocità in uscita per il nodo locale e l'applicazione

Vedere anche

Apertura della connessione PLU
Sessione PLU
Concatenamento in uscita
Concatenamento in ingresso
Consegna del Segmento
parentesi quadre
Direzione
Ritmo e suddivisione in blocchi
Conferma e rifiuto dei dati]
Arresto e disattivazione
Ripristino
Terminazione iniziata dall'applicazione
LUSTATs]
Dati di Monitoraggio tempo di risposta