PDF de programación - Cliente servidor, NFS y NIS - Redes de ordenadores

Informática Técnica de Gestión

Redes de ordenadores

Cliente servidor, NFS y NIS

Grupo de sistemas y comunicaciones



[email protected]

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

1
39.Modelo cliente/servidor

Informática Técnica de Gestión

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

2
39.2 Funciones del cliente/servidor

Informática Técnica de Gestión

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

3
Informática Técnica de Gestión

39.3 Comunicación entre programas

Las aplicaciones no se construyen de forma monolítica. Inicialmente se utilizaban
llamadas a subrutinas y saltos (goto). Pero en los años 70 Wirth, Dijkstra y muchos
otros abogaron por la programación estructurada, que descompone los programas en
procedimientos y funciones que se invocan entre si pasandose parámetros por valor
o por referencia. En los años 80 se reorganiza el código agrupando estos
procedimientos (ahora llamados métodos) con sus variables, constituyendo objetos.

La llamada a procedimiento es pues un concepto aceptado y extensamente utilizado
por los programadores, que además por el volumen de las aplicaciones están
acostumbrados a que estos pedazos de código estén en diversos ficheros, se compilen
por separado y en la última fase, montado, se junten para producir un único ejecutable.

Además la programación concurrente enseña que el flujo de control no tiene por qué
ser único, sino que un proceso puede albergar varios hilos paralelos.

Los sistemas distribuidos incorporan como novedad que los distintos hilos se ejecuten
no solo en pseudoparalelismo en una misma máquina, sino en ordenadores distintos
que se intercomunican mediante una red.

Podríamos pensar que ésto supondrá hacer más compleja la aplicación, y que el
programador necesitará nueva formación para poder aprovecharlo, pero no es así.
Utilizando el concepto de invocación de función se tiene un nivel de abstracción
suficiente para ocultar los detalles de dónde se ejecutará cada parte del código (una
misma aplicación puede luego compilarse como cliente/servidor o como local) y dejar
los detalles de la distribución a la generación del ejecutable y la configuración.

Para el programador es transparente. Por supuesto, quedan detalles como que un
servidor puede recibir llamadas de varios clientes, o que las velocidades de ejecución
relativa si reflejarán si funciona en local o en remoto, pero funcionamente nada cambia.

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

4
Informática Técnica de Gestión

39.4 RPCs

Son un mecanismo genérico de petición de un servicio a otra máquina. Para el
programador, es idéntico al de la llamada a un procedimiento local . La funcionalidad
es similar a la del nivel de sesión OSI. Supone la transferencia de control entre partes
de código que se ejecutan en máquinas diferentes.



El cliente al invocar una llamada
remota, fuerza que se encapsulen los
datos de los parámetros y viajen por la
red hasta el ordenador destino, donde se
crea un entorno para ejecutar la función
servidora. Una vez ejecutada ésta, se
encapsula el resultado para que el
cliente, al recibirlo, pueda seguir con la
ejecución.

La invocación supone un tiempo
empleado en viajar los parámetros y los
resultados, pero puede que la ejecución
de esa función en el servidor compense
en cuanto a velocidad, además de que
probablemente aporte otras ventajas
(compartición de datos para otros
clientes...)

El cliente puede, a diferencia de lo que ocurre en las funciones locales, seguir
haciendo otras operaciones, y solo quedar bloqueado esperando la respuesta cuando
los resultados le sean imprescindibles.

Este paso de mensajes también puede utilizarse para sincronizar procesos.

N

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

5
Informática Técnica de Gestión

39.5 Implementación de RPCs

Las invocaciones a LPCs se suelen basar en el uso de una pila. El compilador ante
una llamada del tipo Nombre_de_procedimiento(Parámetro1, Parámetro2), procede a
meter en la pila los parámetros, y a continuación realizar un salto a posición del código
donde se alberque la subrutina asociada al nombre del procedimiento.

En el caso de las RPCs este mecanismo debe sustituirse por el paso de mensajes,
de manera que el los parámetros se codifiquen en un mensaje junto con la
identificación del procedimiento, y se envíen (según los parámetros de configuración)
al ordenador adecuado, que debe estar preparado para aceptar la llegada del mensaje,
interpretarlo inequívocamente, ejecutar el procedimiento solicitado y generar un
mensaje de respuesta.

El cliente tras la invocación deberá quedar bloqueado pero preparado para recibir un
mensaje de la red, extraer de él el resultado y devolver el control al hilo de la aplicación
que realizó la invocación con el valor cargado como lo habría estado en una LPC.

!El stub o intermediario es el código (generado automáticamente por el sistema de RPCs utilizado)
que suplanta en el clinente la posición de la función invoca y envía por la red los parámetros, queda
a la espera del resultado lo devuelve como si hubiese ejecutado él mismo.
!En el servidor el stub es el programa principal, consistente en un bucle que espera que le llegue por
la red la petición de una de las funciones preparadas, extrae los parámetros, invoca la verdadera
función y envía un mensaje de respuesta resultado.

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

6
39.6 Semántica de las RPCs

Informática Técnica de Gestión

Una importante diferencia con las LPCs es que cuando se invoca una operación
local, o se obtiene un resultado, o el fallo también provoca la destrucción del cliente.
Una RPC puede no tener resultado(el servidor puede caer sin afectar al cliente), y en
ese caso hay que plantearse qué hacer ( reintentarlo, probar con otro servidor, desistir).
La semántica de la invocación puede ser:

Exactly once :Es lo que desearíamos para mantener una absoluta transparencia,
pero no es trivial de conseguir (hay que poner muchas comprobaciones...)
At most once: ejecutalo si puedes, pero nunca más de una vez (no reiterar)
At least once: Reintenta un número (razonable) de veces, hasta conseguirlo.



La invocación reiterada, provocada por la no recepción del resultado en un plazo
razonable, puede conducir a fallos. Puede que la ejecución en el servidor culminase
correctamente y la pérdida del mensaje con el resultado provoque esa nueva
invocación, que puede alterar el resultado pretendido (ejemplo: orden de retirada de
efectivo). La anomalía es consecuencia directa de repetir la operación.

No es lo mismo que el hecho de que el resultado de dos invocaciones idénticas

pueda ser distinto porque se ejecutan en momentos distintos.

Las operaciones que pueden invocarse repetidas veces sin que por ello se altere

el efecto que producen se llaman idempotentes.

Ejemplos:

Consultar el saldo: IDEMPOTENTE (aunque en ese momento otro te ingrese)
Descontar dinero de una cuenta: NO IDEMPOTENTE
Consultar los últimos movimientos: IDEMPOTENTE
Realizar una transferencia: NO IDEMPOTENTE

N

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

7
Informática Técnica de Gestión

3 9.7 Problemática de las RPCs



!El servidor se ejecuta en otro entorno
!No hay variables globales compartidas
!El paso de parámetros es por mensajes, no mediante pila
!Hay que tener en cuenta las respectivas representaciones de los tipos de datos: (enteros de 4 o más
bytes, coma flotante con más o menos bits...)
!Los procesos se ejecutan en máquinas distintas: ¿usan ASCII o EBCDIC? ¿ambas lo mismo?
!Los procesadores tratan de forma distinta los bits: big endian (68000, SPARC) versus little endian
(Intel, VAX), distintos alineamientos de los registros...
! no se pueden pasar punteros (una dirección en un espacio de memoria no tiene sentido en otra
máqina): Hay que pasar los parámetros por copia (valor, no por referencia)
! ¿Cómo pasar ADTs (pilas, colas) o tipos complejos (arrays, estructuras)?
!El proceso invocante debe bloquearse esperando un valor, pero su stub también, con capacidad
para recibir un mensaje por la red.
!Problemas de semántica (transparencia anterior)
!¿Manejo de excepciones?
!Rendimiento: un mensaje tarda en una LAN del orden de milisegundos. Puede resultar más lento
el trasiego que lo que llevaría su ejecución local (si el cliente dispone de los datos necesarios para
ejecutarla por sí mismo).

Como realizar traducciones de cualquier sistema con cualquier otro sería muy
complejo, cada sistema define un formato de representación para la codificación en
línea, de manera que al enviar los datos por la red realiza un proceso denominado
marshalling que representa los valores a intercambiar (de tipos predefinidos) dentro de
los mensajes que van por la red (nivel de presentación).

Los sistemas más conocidos son ASN.1 de OSI, y XDR de ONC (SUN).

La similitud entre el formato de red y el del procesador influye en las prestaciones.

N

R
e
d
e
s

d
e

o
r
d
e
n
a
d
o
r
e
s
,

1
9
9
8
-
1
9
9
9

G
S
Y
C
P
á
g
i
n
a

8
39.8 SUN RPC

Informática Técnica de Gestión

Hay varias especificaciones de RPCs: Courier, de Xerox (la primera), CEDAR

(asociada al lenguaje MESA de Xerox), ARGUS del MIT, DCE, RMI de JAVA..

Una muy difundida (liberada desde el principio en una RFC) es ONC, de Sun,
usada en NFS y NIS. Existen realizaciones de libre distribución, incluyendo
herramientas de ayuda al programador.

Se apoya en XDR (External Data Representation) para obtener la funcionalidad de

nivel de Presentación: Resuelve problemas con orden de bytes en
enteros y números de coma f