Cambios de MUP en Microsoft Windows Vista
Windows Vista implementa una serie de cambios en el proveedor UNC (MUP) múltiple que puede afectar a los redireccionadores de red.
MUP y el cliente del Sistema de archivos distribuido (DFS) están en archivos binarios independientes. El componente MUP está en mup.sys y el cliente DFS está en dfsc.sys. En Windows Server 2003, Windows XP y Windows 2000, el componente de kernel MUP, mup.sys, también contenía el cliente DFS.
Se define un nuevo modelo de redirector en Windows Vista:
MUP se registra como un sistema de archivos con el administrador de E/S llamando a IoRegisterFileSystem.
Un redirector de red se registra con MUP mediante FsRtlRegisterUncProviderEx , una nueva rutina introducida en Windows Vista.
Un redirector de red pasa un objeto de dispositivo sin nombre a FsRtlRegisterUncProviderEx.
Un redirector de red pasa un nombre de dispositivo a FsRtlRegisterUncProviderEx.
Un redirector de red no se registra como un sistema de archivos con el administrador de E/S (no llama a IoRegisterFileSystem).
Todas las llamadas de MUP a un redirector de red, incluida la resolución de prefijos, ioCTLs y FSCTLs, se realizan con las API habilitadas. Se espera que todas las llamadas de otros componentes a MUP se realicen con las API habilitadas. Cuando se usan llamadas con FsRtlCancellableWaitForSingleObject o FsRtlCancellableWaitForMultipleObjects, las nuevas rutinas introducidas en Windows Vista, esto garantizará que se puedan anular las esperas largas si se finaliza un subproceso que emitió una solicitud de E/S.
La resolución de prefijo se realiza mediante IOCTL_REDIR_QUERY_PATH_EX, un nuevo IOCTL introducido en Windows Vista.
Un nombre de dispositivo redirector de red registrado con MUP se convierte en un vínculo simbólico al objeto de dispositivo MUP.
Para un redirector de red conforme al modelo de redirector de Windows Vista, MUP crea un vínculo simbólico en el espacio de nombres del administrador de objetos con el nombre de dispositivo especificado por el redirector de red en la llamada a FsRtlRegisterUncProviderEx. El destino de este vínculo simbólico es el objeto de dispositivo MUP (\Device\Mup).
La ventaja de registrar MUP como sistema de archivos y el nombre del dispositivo del redirector de red es un vínculo simbólico al objeto de dispositivo MUP es que todas las operaciones de E/S del sistema de archivos remotos, y no solo las operaciones basadas en nombres, pasan por MUP. Por lo tanto, los controladores de filtro del sistema de archivos que deben estar en la pila remota del sistema de archivos pueden simplemente asociarse al objeto de dispositivo MUP. Ya no es necesario que los controladores de filtro del sistema de archivos codifiquen los nombres de objetos de dispositivo del proveedor de código duro (\Device\LanmanRedirector, por ejemplo) en su controlador. De este modo, los controladores de filtro del sistema de archivos pueden supervisar todas las operaciones de E/S emitidas a todos los redireccionadores de red mediante un único dato adjunto. Esto también elimina las operaciones de E/S duplicadas que ven los controladores de filtro del sistema de archivos antes de Windows Vista, que se adjuntan por separado a DFS (mup.sys) y a los redireccionadores de red individuales (\Device\LanmanRedirector, por ejemplo) para supervisar las operaciones de E/S en ambos.
Un controlador de filtro del sistema de archivos que está conectado al objeto de dispositivo MUP puede filtrar selectivamente el tráfico que se envía a redireccionadores de red específicos. En esta situación, el controlador de filtro asigna los nombres de dispositivo de los redireccionadores de red de interés a los identificadores de proveedor llamando a la rutina FsRtlMupGetProviderIdFromName . A continuación, el controlador de filtro puede determinar si debe filtrar el tráfico de un objeto de archivo determinado comparando el identificador de proveedor que se obtiene llamando a la rutina FsRtlMupGetProviderInfoFromFileObject con los identificadores de proveedor de los directores de red de interés.
Para un redirector de red conforme al modelo de redirector de Windows Vista:
Todos los objetos de archivo de la pila del sistema de archivos remoto se resuelven en MUP. Por lo tanto, IoGetDeviceAttachmentBaseRef devuelve el objeto de dispositivo para MUP, no el redirector de red que posee el objeto de archivo. Sin embargo, el contenido del objeto de archivo sigue siendo propiedad del redirector de red.
Un IRP_MJ_CREATE emitido al nombre del dispositivo de un redirector de red (\Device\LanmanRedirector\server\share, por ejemplo) se dirige a ese redirector de red sin pasar por la resolución de prefijoS MUP, exactamente como estaba en Windows Server 2003, Windows XP y Windows 2000.
Los redireccionadores de red que no se basan en RDBSS de Windows Vista (vinculación dinámica o estática) se denominan "redireccionadores heredados". Estos redireccionadores de red heredados incluyen:
Redireccionadores de red escritos para Windows Server 2003, Windows XP y Windows 2000 que se registran directamente con MUP mediante FsRtlRegisterUncProvider.
Mini redireccionadores de red escritos para Windows Server 2003, Windows XP y Windows 2000 que se vinculan estáticamente con la biblioteca rdbsslib.lib para Windows Server 2003, Windows XP o Windows 2000.
Redireccionadores de red escritos para Windows Vista que se registran directamente con MUP mediante FsRtlRegisterUncProviderEx.
Los mini-redireccionadores de red que se vinculan dinámicamente con RDBSS de Windows Vista (rdbss.sys) se ajustan automáticamente al modelo de redirector de Windows Vista porque RDBSS se registra con MUP mediante FsRtlRegisterUncProviderEx. Los mini-redireccionadores de red que se vinculan estáticamente con RDBSS de Windows Vista (rdbsslib.lib) también se ajustan automáticamente al modelo de redirector de Windows Vista porque RDBSS se registra con MUP mediante FsRtlRegisterUncProviderEx.
Un redirector de red heredado escrito para Windows Vista que se registra directamente con MUP debe cumplir con el modelo de redirector de Windows Vista.
Los redireccionadores de red escritos para Windows Server 2003, Windows XP y Windows 2000 que se registran directamente con MUP mediante FsRtlRegisterUncProvider siguen funcionando exactamente de la misma manera que en Windows Server 2003, Windows XP y Windows 2000. Los mini-redireccionadores de red escritos para Windows Server 2003, Windows XP y Windows 2000 que se vinculan estáticamente con la biblioteca rdbsslib.lib para Windows Server 2003, Windows XP y Windows 2000 siguen funcionando exactamente igual que en Windows Server 2003, Windows XP y Windows 2000. Estos redireccionadores de red heredados y mini-redireccionadores muestran el siguiente comportamiento:
Estarán visibles para los controladores de filtro del sistema de archivos que supervisan el registro del sistema de archivos.
Sus objetos de dispositivo se denominan . Los nombres de dispositivo no son vínculos simbólicos y no apuntan a \Device\MUP.
Los objetos de archivo se resuelven en el objeto de dispositivo con nombre del redirector de red.
MUP solo está implicado en la operación de resolución de prefijos. Una vez identificado el proveedor de red, MUP "sale del camino" devolviendo STATUS_REPARSE. Todas las operaciones posteriores no pasarán por MUP.
Este comportamiento se ha conservado para evitar el doble filtrado que, de lo contrario, ocurriría si el nombre del dispositivo del proveedor fuera un vínculo simbólico a \Device\MUP. Este doble filtrado se produciría por los siguientes motivos:
El controlador de filtro del sistema de archivos ya está asociado a \Device\MUP.
El controlador de filtro del sistema de archivos se asocia a cualquier sistema de archivos de registro. Dado que los redireccionadores de red que usan objetos de dispositivo con nombre se registran como sistemas de archivos, un controlador de filtro del sistema de archivos acabaría filtrando dos veces la misma E/S.
Las llamadas a y desde MUP en Windows Vista se realizan con LAS API habilitadas, lo que tiene los siguientes impactos:
Es importante proteger, si es necesario, rutas de acceso de código a las que se llama desde MUP en la suspensión de subprocesos por medio adecuado, especialmente IOCTL_REDIR_QUERY_PATH controladores. Tenga en cuenta que una suspensión de subproceso es una operación potencialmente "espera sin enlazar" que puede durar mucho tiempo.
Es importante asegurarse de que cualquier operación de "espera de E/S" que implique subprocesos en modo usuario (en lugar de subprocesos del sistema) siempre use "esperas cancelables". Consulte las rutinas FsRtlCancellableWaitForSingleObject y FsRtlCancellableWaitForMultipleObjects para obtener más información.
Los interbloqueos pueden producirse cuando un subproceso se suspende manteniendo algún bloqueo importante. Es importante ejecutar pruebas en presencia de subprocesos en modo de usuario que se suspenden arbitrariamente para comprobar si hay condiciones de interbloqueo.
Es importante ejecutar pruebas para comprobar si "esperar operaciones de E/S" son realmente cancelables y que una aplicación en modo de usuario puede finalizar un subproceso lo suficientemente rápido como para que la aplicación no parezca estar en un estado "no respondiendo" al intentar finalizar dicho subproceso.
El tamaño y el tiempo de espera de la caché de prefijos usados por MUP en Windows Vista ahora se controlan mediante los siguientes valores del Registro:
PrefixCacheSizeInKB
PrefixCacheTimeoutInSeconds.
Estos valores del Registro se pueden cambiar dinámicamente sin un reinicio. Estos valores del Registro están bajo la siguiente clave del Registro:
HKLM\System\CurrentControlSet\Services\Mup\Parameters.
El valor del Registro ProviderOrder que determina el orden en el que MUP emite solicitudes de resolución de prefijos a redireccionadores individuales se puede cambiar dinámicamente sin reiniciar el sistema. Este valor del Registro se encuentra bajo la siguiente clave del Registro:
HKLM\CurrentControlSet\Control\NetworkProvider\Order
En Windows Vista, MUP realiza la resolución de prefijos de forma diferente en función de si el redirector de red registrado con MUP llamando a FsRtlRegisterUncProvider o FsRtlRegisterUncProviderEx. Los redireccionadores de red heredados que se registran con MUP mediante una llamada a FsRtlRegisterUncProvider recibirán una solicitud de IOCTL_REDIR_QUERY_PATH para la resolución de prefijos. Este es el mismo método que se usa en Windows Server 2003, Windows XP y Windows 2000.
Los redireccionadores de red que se ajustan al modelo de redirector de Windows Vista y se registran con MUP llamando a FsRtlRegisterUncProviderEx recibirán una solicitud de IOCTL_REDIR_QUERY_PATH_EX para la resolución de prefijos. Tenga en cuenta que en Windows Vista, los mini-redireccionadores de red se vinculan estáticamente con rdbsslib.lib o vinculados dinámicamente con rdbss.sys llamarán a FsRtlRegisterUncProviderEx indirectamente a través de RDBSS.
Los búferes de entrada y salida para IOCTL_REDIR_QUERY_PATH_EX son los siguientes:
| Parámetro disponible en | Formato de estructura de datos | |
Búfer de entrada |
IrpSp:> Parameters.DeviceIoControl.Type3InputBuffer |
QUERY_PATH_REQUEST_EX |
Búfer de salida |
IRP-UserBuffer> |
QUERY_PATH_RESPONSE |
El IOCTL y las estructuras de datos se definen en ntifs.h. Los búferes se asignan desde un grupo no paginado.
Los redireccionadores de red solo deben respetar los remitentes en modo kernel de este IOCTL, comprobando que Irp-RequestorMode> es KernelMode.
MUP usa la estructura de datos QUERY_PATH_REQUEST_EX para la información de solicitud.
typedef struct _QUERY_PATH_REQUEST_EX {
PIO_SECURITY_CONTEXT pSecurityContext;
ULONG EaLength;
PVOID pEaBuffer;
UNICODE_STRING PathName;
} QUERY_PATH_REQUEST_EX, *PQUERY_PATH_REQUEST_EX;
| Miembro de estructura | Descripción |
|---|---|
pSecurityContext |
Puntero al contexto de seguridad. |
EaLength |
Longitud, en bytes, del búfer de atributos extendidos. |
pEaBuffer |
Puntero al búfer de atributos extendidos. |
PathName |
Cadena Unicode terminada que no es NULL de la ruta> de acceso al recurso compartido><del servidor><de formularios<. |
Los proveedores UNC deben usar la estructura de datos QUERY_PATH_RESPONSE para la información de respuesta.
typedef struct _QUERY_PATH_RESPONSE {
ULONG LengthAccepted;
} QUERY_PATH_RESPONSE, *PQUERY_PATH_RESPONSE;
| Miembro de estructura | Descripción |
|---|---|
LengthAccepted |
Longitud, en bytes, del prefijo reclamado por el proveedor de la ruta de acceso de cadena Unicode especificada en el miembro PathName de la estructura QUERY_PATH_REQUEST_EX. |
Tenga en cuenta que IOCTL_REDIR_QUERY_PATH_EX es un IOCTL de METHOD_NEITHER. Esto significa que los búferes de entrada y salida podrían no estar en la misma dirección. Un error común por parte de los proveedores UNC es suponer que el búfer de entrada y el búfer de salida son los mismos y usan el puntero del búfer de entrada para proporcionar la respuesta.
Cuando un proveedor UNC recibe una solicitud de IOCTL_REDIR_QUERY_PATH_EX, tiene que determinar si puede controlar la ruta de acceso UNC especificada en el miembro PathName de la estructura QUERY_PATH_REQUEST_EX. Si es así, el proveedor UNC tiene que actualizar el miembro LengthAccepted de la estructura de QUERY_PATH_RESPONSE con la longitud, en bytes, del prefijo que ha reclamado y completado el IRP con STATUS_SUCCESS. Si el proveedor no puede controlar la ruta de acceso UNC especificada, debe producir un error en la solicitud de IOCTL_REDIR_QUERY_PATH_EX con un código de error NTSTATUS adecuado y no debe actualizar el miembro LengthAccepted de la estructura de QUERY_PATH_RESPONSE. Los proveedores no deben modificar ninguno de los demás miembros ni la cadena PathName en ninguna condición.
En Windows Vista, un minidirector de red basado en el uso de RDBSS que indica la compatibilidad como proveedor UNC recibirá esta notificación de prefijo como si fuera una creación de conexión de árbol normal, similar a una llamada Createfile en modo de usuario con FILE_CREATE_TREE_CONNECTION marca establecida. RDBSS enviará una solicitud MRxCreateSrvCall al minidirector de red seguido de una llamada a MRxSrvCallWinnerNotify y MRxCreateVNetRoot. Esta notificación de prefijo no se recibirá como una llamada a MRxLowIOSubmit[LOWIO_OP_IOCTL]. Cuando un minidirector de red se registra con RDBSS, RDBSS copiará la tabla de distribución del controlador para el minidirector de red a través de RDBSS para que apunte a los puntos de entrada internos de RDBSS. A continuación, RDBSS recibe este IOCTL_REDIR_QUERY_PATH_EX internamente para el minidirector de red y llama a MRxCreateSrvCall, MRxSrvCallWinnerNotify y MRxCreateVNetRoot. La IOCTL_REDIR_QUERY_PATH_EX IRP original se incluirá en el RX_CONTEXT pasado a la rutina MRxCreateSrvCall . Además, se modificarán los siguientes miembros del RX_CONTEXT pasados a MRxCreateSrvCall :
El miembro MajorFunction se establece en IRP_MJ_CREATE aunque el IRP original se IRP_MJ_DEVICE_CONTROL.
El miembro PrefixClaim.SuppliedPathName.Buffer se establece en el miembro PathName.Buffer de la estructura QUERY_PATH_REQUEST_EX.
El miembro PrefixClaim.SuppliedPathName.Length se establece en el miembro PathName.Length de la estructura QUERY_PATH_REQUEST_EX.
El miembro Create.ThisIsATreeConnectOpen se establece en TRUE.
El miembro Create.ThisIsAPrefixClaim se establece en TRUE.
El miembro Create.NtCreateParameters.SecurityContext se establece en el miembro SecurityContext de la estructura QUERY_PATH_REQUEST_EX.
El miembro Create.EaBuffer se establece en el miembro pEaBuffer de la estructura QUERY_PATH_REQUEST_EX.
El miembro Create.EaLength se establece en el miembro EaLength de la estructura QUERY_PATH_REQUEST_EX.
El miembro Create.Flags tendrá establecido el bit RX_CONTEXT_CREATE_FLAG_UNC_NAME.
Si el minidirector de red desea ver los detalles de la notificación de prefijo, puede leer estos miembros en la estructura de RX_CONTEXT que se pasa a MRxCreateSrvCall. De lo contrario, solo puede intentar conectarse al recurso compartido del servidor y devolver STATUS_SUCCESS si la llamada MRxCreateSrvCall se realizó correctamente. RDBSS realizará la notificación de prefijo en nombre del minidirector de red.