If the application has enough resources to handle outbound data as fast as the network can provide it (for example, a screen), or if a higher level protocol (for example, immediate request mode) constrains the data flow, then the application need not be involved in pacing, and it is possible for the local node to handle outbound pacing transparently.
However, certain types of applications may require involvement in outbound pacing. If the application has limited resources (for example, a printer), then the application should specify the application pacing option in the CICB on the Open(PLU) OK Response (see Opening the PLU Connection) and provide the local node with information on the state of these resources initially on the Open(PLU) OK Response and periodically using Status-Resource messages.
To assist the application in calculating the initial credit field in the Open(PLU) OK Response, the local node delivers the pacing window sizes and the primary and secondary maximum RU sizes on the Open(PLU) Request. The initial credit must be at least as large as the primary to secondary pacing window size; otherwise the BIND will be rejected and the application will be sent an Open(PLU) Error Confirm message. The local node fills in a suggested initial credit value of one more than the pacing window (to try to avoid stop-start situations).
Note that the local node will also reject the BIND if the application specifies that it wishes to be involved in pacing (of whatever initial credit), but the BIND specifies that there is no outbound pacing.
Only FMD (function management data) requests are part of the credit scheme, so the application must maintain space within its buffer for one Status-Control request per RU in addition to the number of RUs specified by the initial credit count (a Status-Control message takes up 36 bytes).
Each unit of credit that the application delivers to the local node allows the local node to give the application a single RU (or a single chunk if chunking is being used). Note that if the application is receiving segments, then this may correspond to several DATAFMI messages. The application can count RUs for the purpose of outbound flow control by using the BBIU (begin basic information unit) and EBIU (end basic information unit) flags.
The application should maintain a credit-used count, which it should report to the local node on Status-Resource messages. The application needs to take the following actions:
The frequency at which the application provides Status-Resource messages is not architected. However, the local node will only send the application as many Data messages as it has received credit for, and so when the application's credit-used count reaches the initial credit value, the local node will not send any more data. The application should attempt to send a Status-Resource message before this happens, because if the local node cannot send a Data message to the application and the host is still sending requests, the local node may not be able to send a pacing response to the host when required, with a consequent degradation of performance.
If the pacing window is small, such as one or two, the application should send a Status-Resource after processing each DATAFMI message to allow the local node to send the suitable pacing response.
The following figure shows the local node handling outbound pacing when the application is not involved (APPLPAC = 0x00); the pacing window is assumed to be two.
The following figure shows the local node and the application handling outbound pacing with the outbound pacing window assumed to be two and the initial credit from the local node to the application assumed to be four. Note that the local node can send an isolated pacing response (IPR) to the host to get another window full of data as soon as the application has sufficient credit for the rest of the present window and the next window.
