Sistemas operativos modernos

La clave aquí es que el procedimiento cliente, escrito por el usuario, tan sólo emite una lla­ mada a un procedimiento normal (o sea, local) al módulo cliente, que tiene el mismo nombre que el procedimiento servidor. Puesto que el procedimiento cliente y el módulo cliente están en el mismo espacio de direcciones, los parámetros se pasan de la forma acostumbrada. Así mis­ mo, el procedimiento servidor es invocado por un procedimiento de su mismo espacio de direc­ ciones con los parámetros que espera. El procedimiento servidor no percibe nada fuera de lo normal. Así, en lugar de efectuar E/S con send y receive, la comunicación remota se efectúa fin­ giendo una llamada a procedimiento normal. Aspectos de implementación A pesar de la elegancia conceptual de RPC, hay una que otra serpiente oculta en el jardín. Una de las más grandes es el uso de parámetros apuntadores. Comúnmente, no hay problema para pasar un apuntador a un procedimiento. El procedimiento invocado puede utilizar el apuntador igual que el invocador porque los dos procedimientos residen en el mismo espacio de direccio­ nes virtual. Con RPC es imposible pasar apuntadores porque el cliente y el servidor están en espacios de direcciones distintos. En algunos casos pueden usarse trucos para poder pasar apuntadores. Supongamos que el primer parámetro es un apuntador a un entero, k. El módulo cliente puede empacar k y enviarlo al servidor. Entonces el módulo servidor crea un apuntador a y lo pasa al procedimiento ser­ vidor, exactamente como éste lo espera. Cuando el procedimiento servidor devuelve el control al módulo servidor, este úlfimo devuelve k al cliente, donde el nuevo k se copia encima del antiguo, por si el servidor lo modificó. En efecto, la sucesión de invocación estándar de llama­ da por referencia ha sido sustituida por la de copiado-restauración. Lo malo es que este truco no siempre funciona, como cuando el apuntador apunta a un gráfico o a otra estructura de datos compleja. Por este motivo, es preciso imponer algunas restricciones a los parámetros de proce­ dimientos que se invocan de manera remota. Un segundo problema es que en lenguajes con tipos flexibles, como C, es perfectamente váli­ do escribir un procedimiento que calcule el producto interior de dos vectores (arreglos) sin espe­ cificar qué tan grande es cada uno. Cada vector podría terminar con un valor especial que sólo el procedimiento invocador y el invocado conocen. En estas circunstancias, es casi imposible para el módulo cliente empacar los parámettos: no tiene manera de determinar qué tan grandes son. Un tercer problema es que no siempre es posible deducir los tipos de los parámetros, ni si­ quiera a partir de una especificación formal o del código mismo. Un ejemplo es printf, el cual podría tener cualquier canfidad de parámetros (al menos uno) que pueden ser una mezcla arbi­ traria de enteros, cortos, largos, caracteres, cadenas, números de punto flotante de diversas lon­ gitudes, y otros fipos. Tratar de invocar a printf como procedimiento remoto sería casi imposible dada la permisividad de C. Sin embargo, una regla que estipulara que se puede usar RPC a condición de que no se programe en C (o en C 4 -+) no sería muy bien vista. Un cuarto problema fiene que ver con el uso de variables globales. Por lo general, el pro­ cedimiento invocador y el invocado podrían comunicarse empleando variables globales, ade­ más de parámetros. Si ahora el procedimiento invocado se traslada a una máquina remota, el código fallará porque ya no se comparten las variables globales.