INFORMACIÓN: Diferencias entre datos API de control de vínculo en WinNT & DOS

Seleccione idioma Seleccione idioma
Id. de artículo: 156081 - Ver los productos a los que se aplica este artículo
Este artículo se ha archivado. Se ofrece "tal cual" y no se volverá a actualizar.
Expandir todo | Contraer todo

En esta página

Resumen

En este artículo describe las diferencias principales entre la Win32 Data Link Control (DLC) API y la interfaz DLC de DOS. Se supone la familiaridad con el protocolo DLC y los documentos de especificación relevantes. Donde corresponda, también se describen las diferencias de la interfaz de IBM OS/2 DLC.

Más información

La API de DLC de Win32 se ha diseñado para ser como compatible con la API de DLC IBM OS/2 para OS/2 1 xx como sea posible. Los límites de compatibilidad son los impuestas por las funciones de sistema operativo (como eventos frente a semáforos) y los distintos modelos de memoria (planos frente a segmentada).

La API se describe aquí como las diferencias de la interfaz de bloque de control de comandos (CCB) en el IBM LAN Technical Reference, cuarta edición (dic de 1990). Áreas que se tratan en la documentación de IBM generalmente no se repitan aquí.

Diferencias entre el Win32 y API de DLC de OS/2

El siguiente es una lista de las diferencias entre IBM OS/2 DLC y la API de Win32 DLC.
  • Todos los desplazamientos de 16 bits segmento en tablas de parámetro y CCB han sido reemplazados por punteros planos de 32 bits.
  • El grupo de búferes es administrado por el controlador DLC. Las aplicaciones ya no pueden definir el tamaño de segmento del grupo de búferes o agregar búferes nuevos al grupo. Sin embargo, la aplicación debe comprobar siempre el campo tamaño del encabezado de búfer.
  • Los ID. de la aplicación y campos de código de tecla de aplicación de la estructura CCB han procesado obsoletos por la posibilidad de proporcionar un descriptor de seguridad opcional cuando se abre un adaptador.
  • Se quitaron los campos de parámetros específicos de hardware de IBM Token-Ring no se admite por otros adaptadores token-ring comunes. Estos campos no están disponibles en adaptadores Ethernet y las aplicaciones deben en general, evitar su uso.
  • Eventos de Win32 se utilizan en lugar de semáforos de sistema OS/2 para señalar la finalización de las solicitudes de asycnhronous.
  • Todos los recursos globales como dirección funcional, dirección de grupo en Ethernet, vínculo, sap y estaciones directas, que se han compartida por todas las aplicaciones activas están ahora disponibles para cada aplicación por separado.
  • Códigos de tipo Ethernet son compatibles cuando enviando tramas de DIRECT.
  • Las aplicaciones pueden definir una dirección de multidifusión de 48 bits en Ethernet adaptadores. Esta dirección sobrescribe la dirección de difusión de 32 bits establecida por DIR.SET.GROUP.ADDRESS
  • Las aplicaciones pueden enviar varias tramas con el comando TRANSMIT.FRAMES desde una estación DLC.

Diferencias entre el Win32 y API de DLC DOS/2

  • Las rutinas de correos de DLC DOS han reemplazado por una solicitud de lectura.
  • Los búferes de recepción son compatibles con OS/2 1 xx API DLC y son diferentes de los encabezados de recepción de DLC de DOS.
  • Las tablas de parámetro utilizan campos de parámetros específicos de OS/2.
  • Se han implementado no funciones específicas de MS-DOS.

API de Win32 DLC

En general, la mayoría de las funciones y sus bloques de parámetro son idéntica a los de la API de DLC de IBM para 1.xx de OS/2, con los punteros se cambió de desplazamientos de 16 bits a direcciones planas de 32 bits.

Debido a la compatibilidad con la especificación de IBM DLC, todos los de red Ethernet y las direcciones de difusión de las funciones y estructuras de datos que son comunes a Ethernet y redes token ring, usar los encabezados red token ring y haya intercambiado la orden de bits en las direcciones. Las funciones y estructuras de datos que sólo son posibles en el Ethernet utilizan los encabezados de red Ethernet normales y bits de orden. Por ejemplo, tramas DIX de Ethernet utilizan el orden de Ethernet en la recepción y transmisión encabezados de búfer de red. DIR.SET.MULTICAST.ADDRESS utiliza también el orden de Ethernet.

Los tipos de datos, constantes y códigos de error mencionados en las secciones siguientes se documentan en el archivo DLCAPI.H, que se suministra con Microsoft Visual C++ versión 4.0 o el SDK de Win32.

Llamada de API

Los servicios de DLC de Win32 proporcionados por un punto de entrada única de

ASCLAN_STATUS Acslan(PLLC_CCB pCCB, PLLC_CCB * ppBadCCB);

donde:
    pCCB    - Command Control Block, defines the function type and its
              input parameters.
    pBadCCB - Returns the address of the invalid CCB, if server CCBs were
              queued together and one of them failed. The parameter may be
              NULL if the application only specifies one command.

    Return code: ASCLAN status code. The DLC error or success status is
                 always returned in the CCB status field.
				
bloque de control de comandos (CCB) el define parámetros comunes para todas las solicitudes DLC. Los parámetros de solicitud específicas están en una tabla de parámetro externas o en cuatro bytes reservados para ellos en el CCB de Win32. Por ejemplo:

// 
// LLC_CCB - the Command Control Block structure from DLCAPI.H
// 

typedef struct _LLC_CCB {
    UCHAR uchAdapterNumber;         // Adapter
    UCHAR uchDlcCommand;            // DLC command
    UCHAR uchDlcStatus;             // DLC command completion code
    UCHAR uchReserved1;             // reserved for DLC DLL
    struct _LLC_CCB* pNext;         // CCB chain
    ULONG ulCompletionFlag;         // used in command completion
    CCB_PARMS u;                    // parameters
    HANDLE hCompletionEvent;        // event for command completion
    UCHAR uchReserved2;             // reserved for DLC DLL
    UCHAR uchReadFlag;              // set when special READ CCB chained
    USHORT usReserved3;             // reserved for DLC DLL
} LLC_CCB, *PLLC_CCB;
				
donde:
    uchAdapterNumber - Network adapter number, 0, 1, 2.. 255
    uchCommand       - Function code, mostly compatible with IBM spec.
    uchDlcStatus     - DLC return status
    pNext            - Used to chain CCBs. Several Canceled commands or
                       completed TRANSMIT CCBs may be chained with this
                       field. It can also provide a READ command to
                       complete the current command.
    ulCompletionFlag - Optional flag set by READ when the command is
                       completed. The DLC API driver does not use the
                       parameter if it was set to 0 before the call.
    u                - Function-dependent parameter table.
    hCompletionEvent - Event handle which can be used to wait for command
                       completion. This must be created with the Win32 API
                       CreateEvent.
    uchReadFlag      - This should be set if a READ CCB is chained in this
                       command.
				
DLC más comandos sólo se pueden ejecutar de forma sincrónica, con el estado y los parámetros de salida opcionales que se devuelven inmediatamente. Los comandos de E/s de red pueden ser ejecutada sychronously o asincrónica.

Finalización del comando

El comando NT DLC puede realizarse en dos formas:

Esperando en el controlador de eventos definido en el CCB.
-o bien -
Establecer un indicador de finalización en la CCB y leer la finalización de comando con el comando de lectura.

El método de sondeo en el código de estado de la CCB es poco fiable en Windows NT y no debe utilizarse. El campo de estado puede actualizarse antes de los demás parámetros devueltos se han establecido y no se sondeó para su finalización.

Compatibilidad de tipos Ethernet

La especificación de API de DLC para la interfaz directa sólo permite datos encapsulados en marcos 802.5 o 802.3. Esto hace imposible recibir otros tipos de Ethernet. La nueva emisora directa identificadores 0004H y 0005H pueden recibir todos los tipos de Ethernet.

Los usuarios también pueden especificar un tipo específico de trama de Ethernet en el nuevo campo de parámetro del comando DIR.OPEN.STATION. A continuación, la estación directa sólo recibe marcos que tiene ese tipo de trama de Ethernet específico. En el campo de encabezado DLC del encabezado de marco no contiguos, se devuelve el tipo de trama recibidos.

Recibido DIX Ethernet marcos incluyen siempre el relleno de marco, si la longitud de marco es menor que 64 bytes.

El encabezado de Ethernet NET se utiliza cuando una aplicación es enviar o recibir tramas del tipo de Ethernet.

Administración del búfer

Los métodos de asignación y administración del búfer en la API de Win32 DLC son bastante diferentes de los métodos de xx 1 DOS u OS/2. Sin embargo, los encabezados de búfer son como se define en las especificaciones.

Los búferes DLC de Win32 se asignan desde un bloque de memoria virtual único y el controlador DLC define los tamaños de segmento de búfer. Para cada marco recibido asigna una combinación mínimo de 256, 512, 1024, 2048 y 4096 del búfer segmentos (al menos uno de cada tamaño). El algoritmo minimiza la memoria no paginada necesaria para los encabezados de segmento de búfer diferentes (encabezados DLC encabezado de segmento interno y MDL). También asigna el número mínimo de búferes de tramas recibidas. Las aplicaciones pueden solicitar los búferes de tamaño fijo o un número óptimo de búferes para un tamaño de marco.

Los grupos de búferes DLC se expanden dinámicamente desde el umbral de tamaño mínimo de aplicación que especifica si el tamaño de búferes libres es menor que este valor durante un comando READ, DLC.FLOW.CONTROL o BUFFER.GET. El grupo de búferes no puede, sin embargo, aumentarse más allá de su tamaño máximo.

Una aplicación puede utilizar sus propio búferes de transmisión o enviar datos directamente desde el grupo de búferes. Debido a que el controlador DLC bloquea todos los búferes de transmisión que no están en el grupo de búferes, las aplicaciones deben evitar utilizar demasiados búferes de transmisión pequeño.

Utilice los métodos siguientes para obtener un mejor rendimiento:
  • Asignar búferes de transmisión desde el grupo de búfer. Pueden copiar datos a estos búferes de los búferes de usuario.
  • El tamaño máximo negociado de trama debe caben en un único búfer DLC (p. ej., 2048 o 4096 bytes menos los encabezados de marco y el búfer).
  • Recibir varias tramas con el comando de lectura.
  • Utilice el CCB definidas en la estructura LLC_READ_COMMAND.

Funciones de API de DLC

La siguiente sección desglosa las funciones en el conjunto DLC de Win32 que son diferentes de la interfaz CCB2 de la referencia técnica de LAN de IBM. Otras funciones son idénticos a la especificación, excepto en que los punteros son punteros planos de 32 bits.

BUFFER.CREATE 1.

Esta función crea un nuevo grupo de búfer DLC y devuelve su identificador. Todas las estaciones SAP y la estación directa en el mismo número de adaptador utilizan el mismo grupo de búferes. También se puede compartir el mismo grupo de búferes diferentes adaptadores que posee la misma aplicación. Por ejemplo:
   typedef struct _LLC_BUFFER_CREATE_PARMS {
       OUT HANDLE  hBufferPoolHandle;
       IN PVOID        pBuffer;
       IN ULONG        cbBufferSize;
       IN ULONG        cbMinimumSizeThreshold;
   } LLC_BUFFER_CREATE_PARMS, *PLLC_UFFER_CREATE_PARMS;
				

Estructura LLC_BUFFER_CREATE_PARMS

    hBufferPoolHandle - Handle of the created buffer pool. This handle can
                        be used by the same process to share a single
                        buffer pool by several adapter contexts. This
                        handle may be given in the extended parameter
                        table of another DIR.OPEN.ADAPTER command.

    pBuffer           - The application must provide this buffer to
                        the DLC buffer manager. The buffer may be static
                        or allocated from the heap. The buffer manager
                        allocates all DLC buffers from this virtual
                        buffer. This buffer area must not be used for
                        anything else.

    cbBufferSize      - The total size of the buffer. This must be the
                        maximum size of the buffer pool. 0x2000 (hex) is
                        the minimum buffer size, because the buffer manager
                        only uses the full 4K pages.

    cbMinimumSizeThreshold - The buffer manager tries to keep at least this
                             much free space in the buffer pool. The
                             buffer pool is extended by READ, BUFFER.GET
                             and DLC.FLOW.CONTROL commands. This
                             parameter should be big enough to hold all
                             data received between two sequential READ
                             commands. The buffer manager also releases
                             (unlocks) the extra buffer space after a
                             constant time.
				
Todos los segmentos de búfer en un grupo de búfer DLC se asignan desde un bloque de memoria virtual único. Su tamaño es también el tamaño máximo del grupo de búferes. Este comando devuelve un error si no se puede bloquear el tamaño mínimo de búfer dado. Al menos un adaptador debe estar abierto antes de crear grupo de búferes. El comando RECEIVE error si no se ha definido un grupo de búfer para el adaptador.

Las aplicaciones de Windows/NT DLC deben seleccionar cuidadosamente los tamaños de grupo de búfer total y mínimo, porque el Administrador de memoria de Windows y Windows NT tiene una páginas de cuota dinámicos disponibles para cada proceso. Una aplicación de DLC no funcionen en absoluto si intenta asignar demasiado un grupo de búfer en condiciones de poca memoria. Los comandos de transmisión utilizando búferes fuera del grupo de búfer pueden fallar por el mismo motivo.

Las aplicaciones de DLC deben minimizar el tiempo que reciben los búferes de devuelto por los datos o por la solicitud BUFFER.GET se mantienen, porque esos búferes todavía están bloqueados en la memoria. Las aplicaciones de DLC también deben poder recuperar si el controlador de dispositivo DLC se queda sin búferes, porque es posible que no pueda agregar memoria nueva al grupo de búfer (si está ejecutando todo el sistema fuera de la memoria).

En cualquier caso, siempre hay al menos el espacio mínimo de búferes si la solicitud BUFFER.CREATE se ha completado correctamente.

BUFFER.FREE 2.

Esta solicitud devuelve uno o más búferes al grupo del adaptador. No se puede utilizar para agregar nuevos bloques de memoria virtual al grupo existente. Deben haberse obtenidos los búferes con BUFFER.GET

BUFFER.GET 3.

Este comando devuelve los búferes solicitados. El comando puede utilizarse tanto para obtener varios búferes del mismo tamaño o para obtener un conjunto óptimo de búferes para el tamaño de marco determinado.

En el primer caso, cBufferToGet incluye el número de los búferes devueltos y cbBufferSize es el tamaño del segmento de búfer devuelto. El tamaño se redondea al siguiente tamaño de búfer disponible (256, 512, 1024, 2048 ó 4096).

En el segundo caso el número de búferes devueltos debe ser 0 y cbBufferSize incluye el tamaño de la trama real que se copia en los búferes. El Administrador de búfer devuelve suficientes búferes para contener el marco completo, incluido el sus encabezados de búfer. cbBuffersLeft devuelve el tamaño de memoria bloqueado en bloques de 256 bytes o 65536 si el tamaño real es por encima de 1 MB. Por ejemplo:
   typedef struct _LLC_BUFFER_GET_PARMS {
       IN  USHORT          usReserved;
       IN  USHORT          cBuffersLeft;
       IN  USHORT          cBufferToGet;
       IN  USHORT          cbBufferSize;
       OUT PLLC_BUFFER     pFirstBuffer;
   } LLC_BUFFER_GET_PARMS, *PLLC_BUFFER_GET_PARMS;
				

DLC.FLOW.CONTROL 4.

Una aplicación de Windows NT debe emitir este comando inmediatamente cuando una estación de vínculo entra en un estado ocupado local. El controlador borra el estado ocupado cuando hay suficientes búferes para recibir más marcos en el grupo de búferes.

DIR.CLOSE.ADAPTER 5.

Este comando cierra lógicamente el adaptador, liberar todos sus recursos y cancela cualquier comando pendiente. Estaciones SAP o vínculo abiertas se restablecen antes finalización de este comando. Los comandos cancelados devuelven código de error 0x62. Si la aplicación ha establecido previamente bits de la dirección funcional, el software de soporte de adaptador restablece los bits.

DIR.INITIALIZE 6.

Este comando restablece el adaptador de red. Se devuelve sólo el campo BRING_UPS el bloque de parámetros. Están reservados todos los demás campos. Por motivos de seguridad, el comando restablece el adaptador físicamente sólo si el adaptador no estaba funcionando normalmente cuando se emite el comando.

Consulte la "IBM LAN Technical Reference" para obtener más información.

DIR.INTERRUPT 7.

Este comando no hace nada en Windows NT.

DIR.OPEN.ADAPTER 8.

Este comando debe realizarse correctamente antes de que puede iniciar cualquier comunicación de red. No se suele abrirá el adaptador físico, pero los resultados en una lógica abierta. Esto es debido a varias aplicaciones y controladores pueden tener acceso al mismo controlador DLC.

Las aplicaciones pueden tener que proporcionar el parámetro del descriptor de seguridad en la tabla de parámetro.

Se quitaron todos los campos específicos del hardware de IBM Token Ring o la interfaz de NETBIOS de DOS de las tablas de parámetro. La seguridad de DOS y parámetros de grupo de búfer de interfaz directa también son obsoletos.

Se devuelve el resultado de diagnóstico bring telefónico (no está definido en CCB1). De lo contrario, se utilizan las tablas de parámetro de CCB1 y parámetros.

Estructura DIR_OPEN_ADAPTER_PARMS

   typedef struct _LLC_DIR_OPEN_ADAPTER_PARMS {
       PDIR_ADAPTER_PARMS  pAdapterParms;
       PLLC_EXTENDED_ADAPTER_PARMS pExtendedParms;
       PLLC_PARMS          pDlcParms;
       PVOID               Reserved1;
   } LLC_DIR_OPEN_ADAPTER_PARMS, *PLLC_DIR_OPEN_ADAPTER_PARMS;

       pExtendedParms  -    Pointer to new open parameters.
       pAdapterParameters - Pointer to adapter parameter table.
       pDlcParameters     - Pointer to DLC parameter table, see IBM
                            documentation for further information.
				

Estructura EXTENDED_ADAPTER_PARMS

   typedef struct _LLC_EXTENDED_ADAPTER_PARMS {
       HANDLE              hBufferPoolHandle;
       PVOID               pSecurityDescriptor;

   } LLC_EXTENDED_ADAPTER_PARMS, *PLLC_EXTENDED_ADAPTER_PARMS;

       hBufferPoolHandle   - Buffer pool handle returned by a
                             BUFFER.CREATE command.
       pSecurityDescriptor - Windows/Windows NT security descriptor used by
                             all open commands on the adapter.
				
Para obtener más información, consulte "IBM Asymmetric Technical Reference".

DIR.OPEN.DIRECT 9.

No se utilizan los campos que definen el grupo de búferes en la especificación de IBM. Windows proporciona una extensión para recibir tramas de determinados tipos de Ethernet utilizando la estación directa cuando el campo usEthernetType tiene un tipo válido de Ethernet (> 1500).

La máscara de tipo de protocolo, la coincidencia y el desplazamiento pueden utilizarse para recibir tramas para un tipo de subprotocol determinado o un socket. Los parámetros opcionales se omiten si el ulProtocolTypeMask es cero. El desplazamiento define la distancia entre el tipo de protocolo desde el principio del encabezado de protocolo (desplazamiento 14 en el encabezado de marco). La máscara se utiliza para bit a bit y los datos y el resultado deben ser iguales a la coincidencia.

Es decir, se recibe el paquete siempre que:
    (*(PULONG)((PUCHAR)pFrame + 14 + offset) & mask) == match)

   typedef struct _LLC_DIR_OPEN_DIRECT_PARMS {
       IN  USHORT          usReserved[4];
       IN  USHORT          usOpenOptions;
       IN  USHORT          usEthernetType;
       IN  ULONG           ulProtocolTypeMask OPTIONAL;
       IN  ULONG           ulProtocolTypeMatch OPTIONAL;
       IN  USHORT          usProtocolTypeOffset OPTIONAL;
   } LLC_DIR_OPEN_DIRECT_PARMS, *PLLC_DIR_OPEN_DIRECT_PARMS;
				

DIR.READ.LOG 10.

Algunos adaptadores de red pueden no admite todos los campos de parámetro de esta función porque la implementación de contadores de error es opcional en NDIS 3.0. Estos campos son compatibles con controladores proporcionados por Microsoft NDIS 3.0, incluidas IBM Token Ring.

DIR.SET.FUNCTIONAL.ADDRESS 11.

En Ethernet, cada bit establecido en las direcciones funcionales token-ring hace que una asignación a una dirección de multidifusión Ethernet. Por favor, consulte la "IBM LAN Technical Reference" para obtener más información.

DIR.SET.MULTICAST.ADDRESS 12.

Este comando establece una dirección de multidifusión de 48 bits para el contexto de adaptador DLC abierto actualmente. Un valor cero quita la anterior dirección de multidifusión. Este comando sólo se admite en redes Ethernet y es una alternativa a la función DIR.SET.GROUP.ADDRESS que sólo se puede establecer los 32 bits más bajos de una dirección de multidifusión. Esta operación puede fallar si el adaptador de Ethernet no tiene una dirección de multidifusión.

El orden de bits de la dirección de multidifusión es el orden de bits normal de Ethernet.

DIR.SET.GROUP.ADDRESS 13.

Sólo una aplicación puede establecer una dirección de grupo para un adaptador token ring. Esta operación también puede fallar si el adaptador de Ethernet no tiene direcciones de multidifusión disponibles.

LECTURA DE 14.

Como en la especificación de IBM, salvo que todos los campos de la tabla de parámetro se alinean naturalmente. También está alineado el búfer no contiguo. Los datos y el encabezado opcional comienzan en desplazamiento 64.

15.READ.CANCEL

Como en la especificación CCB2, excepto que el pParameter del campo en CCB del comando sirve para especificar el puntero CCB del comando cancelado.

RECEPCIÓN DE 16.

No se admite la opción de recepción 5 (INTER).

RECEIVE.CANCEL 17.

Utiliza el campo pParameter del CCB para señalar al puntero CCB del comando cancelado.

Comandos de MS-DOS no compatibles

Los siguientes comandos DOS DLC no son compatibles con Windows NT:
  • DIR.SET.USER.APPENDAGE
  • RECEIVE.MODIFY
  • DIR.RESTORE.OPEN.PARMS
  • DIR.MODIFY.OPEN.PARMS

GUAU/DOS DLC

DLC servicios están disponibles en aplicaciones de MS-DOS que se ejecutan en el entorno WOW y DOS en Windows NT. La API es directamente compatible con emuladores de IBM existentes mediante la API de DLC de DOS en DOS.

Windows aplicaciones que se comunican con DOS terminate-and-stay-resident (TSR) para tener acceso a servicios DLC también deberían funcionar sin modificaciones en WOW.

Referencias

-"SC30 de referencia de IBM LAN técnico-3383." Este documento describe el conjunto básico de funciones de CCB2 como se utiliza por EE de OS/2.
  • DLCAPI.H

Propiedades

Id. de artículo: 156081 - Última revisión: sábado, 22 de febrero de 2014 - Versión: 4.1
La información de este artículo se refiere a:
  • Microsoft Win32 Application Programming Interface sobre las siguientes plataformas
    • Microsoft Windows NT 3.51 Service Pack 5
    • the operating system: Microsoft Windows 2000
Palabras clave: 
kbnosurvey kbarchive kbmt kbapi kbinfo kbnetwork KB156081 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 156081

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com