Velocidad de salida

Si la aplicación tiene suficientes recursos para administrar los datos de salida tan rápido como la red puede proporcionarlos (por ejemplo, una pantalla), o si un protocolo de nivel superior (por ejemplo, el modo de solicitud inmediata) restringe el flujo de datos, la aplicación no necesita participar en la velocidad, y es posible que el nodo local administre el ritmo de salida de forma transparente.

Sin embargo, ciertos tipos de aplicaciones pueden requerir la participación en la velocidad de salida. Si la aplicación tiene recursos limitados (por ejemplo, una impresora), la aplicación debe especificar la opción de velocidad de la aplicación en el bloque de control de información de conexión (CICB) en la respuesta Open(PLU) OK Response. (Para obtener más información, vea Apertura de la conexión de PLU). La aplicación también debe proporcionar al nodo local información sobre el estado de estos recursos inicialmente en Open(PLU) OK Response y usando periódicamente los mensajes Status-Resource.

Para ayudar a la aplicación a calcular el campo de crédito inicial en Open(PLU) OK Response, el nodo local proporciona los tamaños de ventana de velocidad y los tamaños máximos de la unidad de solicitud/respuesta (RU) principal y secundaria en la solicitud Open(PLU). El crédito inicial debe ser al menos tan grande como el tamaño de la ventana de velocidad primaria a secundaria. De lo contrario, se rechazará BIND y se enviará a la aplicación un mensaje Open(PLU) Error Confirm. El nodo local rellena un valor de crédito inicial sugerido de uno más que la ventana de velocidad (para intentar evitar situaciones de parada-arranque).

Tenga en cuenta que el nodo local también rechazará BIND si la aplicación especifica que debe participar en la velocidad (de cualquier crédito inicial), pero BIND especifica que no hay ninguna velocidad de salida.

Solo las solicitudes de datos de administración de funciones (FMD) forman parte del esquema de crédito, por lo que la aplicación debe mantener espacio dentro de su búfer para una solicitud Status-Control por RU, además del número de RU especificado por el recuento de crédito inicial. (Un mensaje Status-Control ocupa 36 bytes).

Cada unidad de crédito que la aplicación entrega al nodo local permite que el nodo local proporcione a la aplicación una sola RU (o un único fragmento si se usa la fragmentación). Tenga en cuenta que si la aplicación está recibiendo segmentos, esto puede corresponder a varios mensajes DATAFMI. La aplicación puede contar las RU con el fin de controlar el flujo de salida utilizando los indicadores de unidad de información básica inicial (BBIU) y unidad de información básica final (EBIU).

La aplicación debe mantener un recuento de crédito utilizado, que debe comunicar al nodo local en los mensajes Status-Resource. La aplicación debe realizar las siguientes acciones:

• Al procesar (no recibir) los mensajes DATAFMI con la EBIU configurada (correspondientes a solicitudes de FMD), incrementa en uno el recuento de crédito utilizado.

• Al procesar los mensajes Status-Control y todos los demás mensajes del nodo local, no se incrementa el recuento de crédito utilizado.

• Informe periódicamente del número actual de crédito utilizado en un mensaje Status-Resource.

• Informe del recuento de crédito utilizado cuando su búfer se quede vacío (sea cual sea el último mensaje procesado), a menos que el recuento de créditos utilizados sea cero.

• Cuando el recuento de crédito utilizado se notifique al nodo local, restablézcalo a cero.

  La frecuencia con la que la aplicación proporciona mensajes Status-Resource no forma parte del diseño. Sin embargo, el nodo local solo enviará a la aplicación tantos mensajes Data como crédito haya recibido. Cuando el recuento de crédito utilizado de la aplicación alcanza el valor de crédito inicial, el nodo local no enviará más datos. La aplicación debe intentar enviar un mensaje Status-Resource antes de que esto suceda, porque si el nodo local no puede enviar un mensaje Data a la aplicación y el host sigue enviando solicitudes, es posible que el nodo local no pueda enviar una respuesta de velocidad al host cuando sea necesario, con una degradación consiguiente del rendimiento.

  Si la ventana de velocidad es pequeña (de uno o dos, por ejemplo), la aplicación debe enviar Status-Resource después de procesar cada mensaje DATAFMI para permitir que el nodo local envíe la respuesta de velocidad adecuada.

  En la ilustración siguiente se muestra el nodo local administrando la velocidad de salida cuando la aplicación no participa (APPLPAC = 0x00). Se supone que la ventana de velocidad está establecida en dos.

  
  Control de la velocidad de salida del nodo local

  En la ilustración siguiente se muestra el nodo local y la aplicación que administra la velocidad de salida, con una supuesta ventana de velocidad de salida de dos y un supuesto crédito inicial del nodo local a la aplicación de cuatro. Tenga en cuenta que el nodo local puede enviar una respuesta de velocidad aislada (IPR) al host para obtener otra ventana llena de datos en cuanto la aplicación tenga crédito suficiente para el resto de la ventana actual y la ventana siguiente.

  
  Nodo local y aplicación que administra la velocidad de salida

Consulte también

Apertura de la conexión de PLU
Sesión de PLU
Encadenamiento de salida
Encadenamiento de entrada
Entrega de segmentos
Brackets
Dirección
Velocidad y fragmentación
Confirmación y rechazo de datos]
Apagado y modo inactivo
Recuperación
Terminación iniciada por la aplicación
LUSTATs]
Datos del Monitor de tiempo de respuesta