Sistemas operativos modernos

Cliente Servidor Colaborador Servidor encapsulado Figura 9-33. a) Los procesos cliente, servidor y colaborador, b) El servidor encapsula­ do todavía puede filtrar información al colaborador a través de canales encubiertos. enviando un Oque cuando esté enviando un 1. Este canal de comunicación se denomina canal en­ cubierto y se ilustra en la figura 9-33b. Desde luego, el canal encubierto es un canal ruidoso, que contiene mucha información ajena, pero es posible enviar información de manera fiable por un canal ruidoso ufilizando un código de corrección de errores (por ejemplo, un código Hamming, o incluso algo más complejo). El uso de un código de corrección de errores reduce aún más el ya de por sí bajo ancho de banda del canal encubierto, pero podría ser suficiente para filtrar una canfidad considerable de infor­ mación. Es bastante obvio que ningún modelo de protección basado en una matriz de objetos y dominios va a evitar este fipo de filtraciones. La modulación del uso de la CPU no es el único canal encubierto. También es posible mo­ dular la tasa de paginación (muchos fallos de página para indicar un 1 , ningún fallo de página para indicar un 0). De hecho, es candidata casi cualquier forma de degradar el desempeño del sistema en relación con el fiempo. Si el sistema ofrece algún mecanismo para bloquear archi­ vos, el servidor puede bloquear un archivo para indicar un 1 , y desbloquearlo para indicar un 0. En algunos sistemas, un proceso puede detectar el estado de un bloqueo incluso en archivos a los que no fiene acceso. Este canal encubierto se ilustra en la figura 9-34, donde el archivo está bloqueado o desbloqueado durante algún intervalo fijo que conocen tanto el servidor co­ mo el colaborador En este ejemplo se está transmitiendo el flujo secreto de bits 11010100. Bloquear y desbloquear un archivo previamente acordado, 5, no es un canal demasiado rui­ doso, pero sí requiere una temporización cuidadosa a menos que la tasa de bits sea muy baja. La confiabilidad y el desempeño pueden mejorarse empleando un protocolo de acuse de recibo. Este protocolo emplea dos archivos más, F l y F2, bloqueados por el servidor y el colaborador, respecfivamente, para mantener la sincronización entre los dos procesos. Después de que el servidor bloquea o desbloquea 5, cambia el estado del bloqueo de F l para indicar que se en­ vió un bit. Tan pronto como el colaborador lee el bit, cambia el estado del bloqueo de F2 para indicar al servidor que está listo para otro bit y espera hasta que el bloqueo de F l cambie de estado para indicar que hay otro bit en S. Puesto que ya no se requiere temporización, este pro­ tocolo es confiable por completo, incluso en un sistema ocupado, y puede proceder tan rápido como los dos procesos puedan calendarizarse. Para obtener un mayor ancho de banda, ¿por qué