Transcript Servidor - WordPress.com

PRIMITIVAS DE SESIÓN EN OSI
Rq
In
Rs
Cn
SIGNIFICADO
S-CONNECT
Establece una conexion
S-RELEASE
Termina una sesión de forma gradual
S-U-ABORT
Liberación abrupta iniciada por el usuario
S-P-ABORT
Liberación abrupta iniciada por el proveedor
S-DATA
Transferencia de datos normales
S-EXPEDITED-DATA
Transferencia de datos expeditivos
S-TYPED-DATA
Transferencia de datos fuera-de-banda
S-CAPABILITY-DATA
Controla la trasferencia de datos
S-TOKEN-GIVE
Pasa el token a la otra capa
S-TOKEN-PLEASE
Pide un token a la otra capa
S-CONTROL-GIVE
Pasa todos los tokens a la otra capa
S-SYNC-MAJOR
Inserta un punto de sincronización mayor
S-SYNC-MINOR
Inserta un punto de sincronizacion menor
S-RESYNCHRONIZE
Volver
a
un
punto
sincronización previo
de
S-ACTIVITY-START
Comienza una actividad
S-ACTIVITY-END
Termina una actividad
S-ACTIVITY-DISCARD
Abandona una actividad
S-ACTIVITY-INTERRUPT
Suspende una actividad
S-ACTIVITY-RESUME
Retoma
una
actividad
previamente suspendida
S-U-EXCEPTION-REPORT
Informa de una excepción de
usuario
S-P-EXCEPTION-REPORT
Informa de una excepción del
proveedor
S-UNITDATA
Transferencia
conexión
de
datos
sin
EVOLUCIÓN DEL PROTOCOLO
Modelo Cliente Servidor: Es el modelo estándar de ejecución de
aplicaciones en red . Al hablar de las bases de datos, servidores web, ftp
y correo.
Servidor: Es un proceso que se esta ejecutando en un nodo de la red y
que gestiona el acceso a un determinado recurso.
Cliente: Es un proceso que se ejecuta en el mismo o diferente nodo y
que realiza peticiones de servicio al servidor. Las peticiones están
originadas por la necesidad de acceder al recurso que gestiona el
servidor.
El servidor esta continuamente esperando peticiones de servicio, es decir:
cuando se produce una petición, el servidor despierta y atiende al cliente.
Cuando el servicio concluye, el servidor vuelve al estado de espera. De
acuerdo con la forma de prestar el servicio, se tienen dos tipos de
servidores:
 Servidores interactivos
 Servidores concurrentes
Servidores de Impresión
Servidores de Archivos
Servidores de Bases de Datos
Servidores de Lotus Notes
La forma genérica que van a tener los diagramas de flujo de control, tanto los
servidores como los clientes se muestran en los pasos y figura siguientes:
Abrir el canal de comunicaciones e informar a la red tanto de la dirección a la que
responderá como de su disposición para aceptar peticiones de servicio.
Esperar a que un cliente le pida el servicio en la dirección que el tiene declarada.
Cuando recibe una petición de servicio, si es un servidor interactivo, atenderá al
cliente. Los servidores interactivos se suelen implementar cuando la respues que
necesita el cliente es sencilla e implica poco tiempo de proceso.
Volver al punto 2 esperar nuevas peticiones del servicio.
El programa cliente, por su parte, llevara a cabo las siguientes acciones:
1. Abrir el canal de comunicaciones y conectarse a la dirección de red
atendida por el servidor. Naturalmente, esta dirección debe ser
conocida por el cliente y responderá al esquema de generación de
direcciones de la familia de sockets que este empleando.
2. Enviar al servidor un mensaje de petición de servicio y esperar hasta
recibir la respuesta.
3. Cerrar el canal de comunicaciones y terminar la ejecución.
Proceso cliente
Proceso servidor
Abrir el canal de
comunicación
Abrir el canal de
comunicación
Comunicar a la red la
dirección del canal
Conectar con la
dirección del servidor
Pedir servicio
Esperar petición
de servicio
Esperar
respuesta
fork
Atender al
cliente
Fin del proceso
hijo
Fin del proceso
cliente
 La existencia de plataformas de hardware cada vez más baratas
 El esquema Cliente/Servidor facilita la integración entre sistemas
diferentes y comparte información
 El uso del esquema Cliente/Servidor es que es más rápido el
mantenimiento y el desarrollo de aplicaciones
 El crecimiento de la infraestructura computacional, favoreciendo así la
escalabilidad de las soluciones.
 El mantenimiento de los sistemas es más difícil
 Se cuenta con muy escasas herramientas para la administración y ajuste
del desempeño de los sistemas.
 Es importante que los clientes y los servidores utilicen el mismo
mecanismo (por ejemplo sockets o RPC)
 Además, hay que tener estrategias para el manejo de errores y para
mantener la consistencia de los datos.
 La seguridad de un esquema Cliente/Servidor
 El desempeño es otro de los aspectos que se deben tener en cuenta en el
esquema

RPC es un protocolo de Sun Microsystem propuesto como estándar.
Su status es electivo. Es usado por muchos distribuidores de sistemas
UNIX, y permite el desarrollo de sistemas de procesamiento
distribuido basados en el paradigma procedimental.

El RPC es una interfaz de programación de aplicación (API)
disponible para el desarrollo de aplicaciones distribuidas. Nos
permite que los programas llamen a subrutinas que se ejecutan en
un sistema remoto.
El programa denominado cliente envía un mensaje de llamada
al proceso servidor y espera por un mensaje de respuesta. La
llamada incluye los parámetros del procedimiento y la
respuesta los resultados.
 Una llamada a un procedimiento (función o subrutina) es una
método bien conocido para transferir el control de una parte
del programa a otra, con un retorno de control a la primera.
Asociado con la llamada a un procedimiento están el pase de
argumentos y el retorno de uno o varios resultados.
 Un RPC, el sistema local invoca a través de la red, a una
función alojada en otro sistema.

El RPC de Sun consta de las siguientes partes:
RPCGEN
 XDR
 Librería “run-time”


El concepto de RPC se simplifica de la forma siguiente:
› El concepto que llama, envía un mensaje de llamada y espera
por la respuesta.
› En el lado del servidor un proceso permanece dormido a la
espera de mensajes de llamada. Cuando una llamada llega, el
proceso servidor extrae los parámetros del procedimiento,
calcula los resultados y los devuelve en un mensaje de
respuesta.

1. El cliente llama a un procedimiento local llamado “stub” del cliente,
el cual aparenta ser el procedimiento servidor que el cliente desea
llamar. El empaquetamiento de los argumentos del procedimiento
remoto en mensajes de red se conoce como “marshaling”.

2. Estos mensajes son enviados por el “stub” del cliente al sistema
remoto, lo cual requiere una llamada del sistema.

3. Los mensajes son transferidos al sistema remoto empleando
protocolos con o sin conexión.

4. Un procedimiento “stub” del servidor espera en el sistema remoto la
solicitud del cliente. Desempaqueta los argumentos de los mensajes
de red y si es necesario realiza alguna conversión.

5. El “stub” del servidor realiza la llamada al procedimiento local que
realmente invoca la función del servidor y le pasa los argumentos
transferidos a través de la red desde el “stub” del cliente.

6. Cuando el procedimiento del servidor termina, éste le regresa el
control al “stub” del servidor devolviendo los resultados obtenidos.

7. El “stub” del servidor adecua el formato de tales resultados, si es
necesario, y los empaqueta en mensajes de red para ser devueltos
al “stub” del cliente.

8. Los mensajes son transmitidos al “stub” del cliente.

9. El “stub” del cliente lee los mensajes recibidos.

10. Luego de posiblemente convertir los valores de retorno, el “stub”
del cliente retorna finalmente dichos resultados a la función del
cliente haciendo parecer un retorno normal de función.

El concepto de llamada a procedimiento remoto permite ocultar
en los “stubs” todos los detalles del código correspondiente a la
comunicación a través de la red. Esto permite que los
desarrolladores de programas de aplicación no se preocupen por
detalles tales como “sockets” y ordenamiento de bytes. Uno de los
objetivos de RPC es facilitar el desarrollo de aplicaciones
distribuidas.

Las RPC son muy utilizadas dentro del paradigma cliente servidor.
Siendo el cliente el que inicia el proceso solicitado al servidor que
ejecute cierto procedimiento o función y enviando éste de vuelta
el resultado de dicha operación al cliente.

Las implementaciones de RPC más populares son:
› La desarrollada por Sun Microsystem denominada ONC-RCP (Open
Network Computing, ONC-RCP), distribuida con casi todos los sistemas
UNIX.
› La desarrollada por Microsoft en línea con el Ambiente de Computación
Distribuida (DCE, Distributed Computing Enviroment) definido por la
Fundación de Software Abierto (OSF, Open Software Foundation). Incluida
en los sistemas operativos Windows.

Este documento describe mayormente la implementación ONC–RCP gracias a
su sencillez y mayor difusión en entornos cliente/servidor, producto de su
distribución junto a sistemas UNIX. Adicionalmente, se han identificado y
realizado pruebas de interoperabilidad con implementaciones en lenguaje C
para plataforma Windows y en Java, lo cual le abre una nueva dimensión a
esta tecnología dándole una verdadera capacidad multiplataforma.

Un ejemplo de la aplicación de esta tecnología es el Sistema de Archivos en
Red (NFS, Network File System), disponible en la mayoría de plataformas UNIX.

Como se mencionó anteriormente, esta implementación fue
desarrollada inicialmente por Sun Microsystem y está disponible en
la gran mayoríade los sistemas UNIX. La especificación de ONC-RPC
versión 2 está descrita en la RFC 1831 (Agosto, 1995). La RFC 1832
provee la descripción de XDR (Agosto, 1995).

ONC-RPC cuenta con los siguientes componentes:
› rpcgen, un compilador que toma la definición de la interfaz de
un procedimiento remoto y genera el “stub” del cliente y el
“stub” del servidor.
› XDR (eXternal Data Representation), un estándar para la
descripción y codificación de datos que garantiza portabilidad
entre sistemas de arquitecturas diferentes.
› Una librería que maneja todos los detalles.