Download - CAPA DE SESIÓN 7.3 SERVICIOS DE NIVEL SESIÓN 7.4 LLAMADAS A PROCEDIMIENTOS REMOTO (RPC) EQUIPO:
CAPA DE SESIÓN
7.3 SERVICIOS DE NIVEL SESIÓN7.4 LLAMADAS A PROCEDIMIENTOS
REMOTO (RPC)
EQUIPO:CAB SALINAS ANIBAL JOSÉFERNÁNDEZ LANDAVERDE VERÓNICAHERNÁNDEZ ÁLVAREZ DAVIDROSAS ZARCO ARIADNA DANAE
REDES DE DATOS
GRUPO: 02
CAPA DE SESION
Permite a los usuarios de diferentes maquinas de una red establecer sesiones entre ellos. A través de una sesión se puede llevar a cabo un transporte de datos ordinario, aunque esta capa se diferencia de la de transporte en los servidos que proporciona.
SESIONES DE COMUNICACIÓN
Esta capa establece, administra y termina las sesiones de comunicación entre dispositivos. Una sesión de comunicación consta de solicitud de servicio y respuesta al servicio entre dos aplicaciones.
Protocolos de esta capa conocidos: Apple Talk, ZIP ( Protocolo de Información de Zona) CAPA DE SESIÓN SESIÓN 5
OBJETIVO DE LA CAPA DE SESIÓN
La capa de sesión permite que los usuarios de diferentes maquinas puedan establecer sesiones entre ellos. A través de una sesión se puede llevar a cabo un transporte de datos ordinario, tal y como lo hace la capa de transporte, pero mejorando los servicios que esta proporciona y que se utilizan en algunas aplicaciones.
Una sesión podría permitir al usuario acceder a un sistema de tiempo compartido a distancia, o transferir un archivo a distancia.
FUNCIONES ESENCIALES
Esta encargada de proporcionar sincronización y gestion de testigos.Establece, administra y finaliza las sesiones entre dos host que se estan comunicando.Restaura la sesion a partir de un punto seguro y sin perdida de datos.Sincroniza el dialogo entre las capas de presentación de los host y administra su intercambio de datos.Sincroniza el dialogo entre las capas de presentación de los host y administra su intercambio de datos.Ofrece disposiciones para una eficiente transferencia de datos.o Manejar tokens. Hacer checkpoints.Cronometra y controla el flujo.
PROTOCOLOS IMPORTANTES
ADSP, AppleTalk Data Stream ProtocolASP, AppleTalk Session ProtocolH.245, Call Control Protocol for Multimedia CommunicationISO-SP, OSI Session Layer Protocol (X.225, ISO 8327)iSNS, Internet Storage Name ServiceL2F, Layer 2 Forwarding ProtocolL2TP, Layer 2 Tunneling ProtocolNetBIOS, Network Basic Input Output SystemPAP, Password Authentication ProtocolPPTP, Point-to-Point Tunneling ProtocolRPC, Remote Procedure Call ProtocolRTCP, Real-time Transport Control ProtocolSMPP, Short Message Peer-to-PeerSCP, Secure Copy ProtocolSSH, Secure ShellZIP, Zone Information Protocol
INTERCAMBIO DE DATOS
La característica más importante de la capa de sesión es el Intercambio de datos. Una sesión sigue un proceso de tres fases:
1.ESTABLECIMIENTO 2. UTILIZACIÓN 3. LIBERACION
1. ESTABLECIMIENTO
En el establecimiento de una sesión un usuario de sesión invoca una primitiva S-CONNECT.request con el objeto de establecer una sesión, el proveedor de sesión solo ejecuta un T-CONNECT.request para establecer una conexión de transporte.
De la misma manera, el establecimento de una sesión, al igual que el establecimiento de un conexión de transporte, implica una negociación entre los corresponsales (usuarios) para fijar los valores de varios parámetros como pueden ser la calidad de servicio, y la bandera indicando si los datos acelerados están o no permitidos. Estos se pasan a la conexión de transporte sin que se les haga modificación alguna.
3. LIBERACIÓN
En la liberación existen importantes diferencias entres una sesión y una conexión de transporte. La principal entre esta es la forma de cómo se liberan las sesiones y las conexiones de transporte. Las conexiónes de trasnporte terminan con la primitiva T-DISCONNECT.request, que produce una liberación abrupta y puede traer como resultado la perdida de los datos en trafico que haya en el momento de la liberación.
Las sesiones se terminan con la primitiva S-RELEASE.request que resulta en una liberación ordenada en la cual los datos no se llegan a perder.
ADMINISTRACIÓN DEL DIALOGO
En principio, todas las conexiones del modelo OSI son dúplex, es decir, las unidades de datos del protocolo(PDU) se pueden mover en ambas direcciones simultáneamente sobre la misma conexión. Aunque puede haber situaciones en las que el software de capas superiores esta estructurado de tal forma que espera que los usuarios tomen turno convirtiendo la comunicación en semidúplex.
SINCRONIZACIÓN
Los usuarios pueden insertar puntos de sincronización en el flujo del mensaje. Cada uno de estos puntos lleva un número de sede. Cuando un usuario invoca una primitiva para solicitar un punto de sincronización, el otro obtiene una indicación. De la misma manera si uno de ellos invoca una primitiva para resincronización el otro también obtiene una indicación de esto. El almacenamiento de los mansajes y la subsiguiente retransmisión posterior se lleva a cabo arriba de la capa de sesión; lo que la capa de sesión proporciona es una forma de transportar señales de sincronización y resincronización numeradas a través de la red.
ADMINISTRACIÓN DE ACTIVIDADES
Permite que el usuario divida el flujo de mensajes en unidades lógicas denominadas actividades. Cada actividad es completamente independiente de cualquiera de las demás que pudieron haber venido antes o que vendrán después de ella. En una transferencia de archivo que se inicia como una actividad. En un momento del proceso de transferencia es posible emitir una primitiva S-ACTIVITY-INTERRUPT.request, para suspender la transferencia del archivo. Entonces, se puede iniciar y completar otra actividad, y finalmente la actividad original puede reiniciarse desde el punto en el que se interrumpió.
NOTIFICACIÓN DE EXCEPCIONES
Otra característica de la capa de sesión es la correspondiente a un mecanismo de propósito general para notificar errores inesperados. Si un usuario tiene algún problema, por cualquier razón, este problema se puede notificar a su corresponsal utilizando la primitiva S-U-EXCEPTION-REPORT.request.
La notificación de excepciones no solamente se aplica a los errores detectados del usuario. El proveedor del servicio puede generar una primitiva S-P-EXCEPTION-REPORT. indicación para informarle al usuario sobre los problemas internos que existen dentro de la capa de sesión, o sobre problemas que le reporten procedentes de las capas de transporte o inferiores.
Recuperación
La capa de sesión puede proporcionar un procedimiento de puntos de comprobación, de forma que si ocurre algún tipo de fallo entre puntos de comprobación, la entidad de sesión puede retransmitir todos los datos desde el último punto de comprobación y no desde el principio.
ORGANIZACIÓN DEL DIÁLOGOCONEXIONES DE SESIÓN /
TRANSPORTE
Distintas posibilidades:1.-Una conexión de sesión en una de transporte
2. Varias conexiones de sesión en una de transporte
Nota: No se pueden multiplexar varias conexiones
simultaneas.
ACTIVIDADES
Es posible diferenciar en una conexión distintas etapas independientes, denominadas Actividades en la terminología OSI. Permiten al usuario organizar el flujo de datos.
La diferenciación entre actividades es responsabilidad de la aplicación. Por ejemplo, en un intercambio de archivos, el envío de cada uno puede gestionarse como una actividad.
Un posible uso es el de "poner en cuarentena" las peticiones recibidas hasta que finalice la actividad, evitando bloqueos. Las actividades pueden interrumpirse, reanudarse o ser abandonadas. No es posible solapar dos o más actividades.
Por último, una actividad puede descomponerse en una o más unidades de diálogo:
Para evitar el inicio de actividades simultáneas desde ambos extremos del diálogo, la administración de actividades se controla mediante un testigo.
TESTIGOS (TOKENS)
Son derechos que permiten invocar distintos servicios y que se asignan dinámicamente entre los interlocutores. El servicio asociado a un testigo sólo puede ser invocado por su poseedor.
TIPOS DE TESTIGOS:
- De datos- De liberación de conexión- De sincronización menor- De sincronización mayor y actividad
UTILIZACIÓN
-El testigo de datos permite mantener diálogos bidireccionales no simultáneos, con cesión de turno de palabra, o bien idireccionales simultáneos en su ausencia
-Para introducir puntos de sincronización menor se requieren los testigos de datos y sincronización menor.
- Para introducir puntos de sincronización mayor se requieren los testigos de datos, sincronización menor y mayor.
Resincronización
Lleva la conexión de sesión a un estado definido que se ha identificado con el número de serie del punto de sincronismo utilizado.
La resincronización puede ser invocada por cualquier usuario. Sólo es posible resincronizar hasta el último punto de sincronismo mayor.
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 de sincronización previo
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
PROTOCOL DATA UNIT
PDUs (en inglés, Protocol Data Units), Unidades de Datos de Protocolo. Se utiliza para el intercambio entre unidades parejas, dentro de una capa del modelo OSI. Existen dos clases de PDUs:
PDU de datos, que contiene los datos del usuario final (en el caso de la capa de aplicación) o la PDU del nivel inmediatamente superior.
PDU de control, que sirven para gobernar el comportamiento completo del protocolo en sus funciones de establecimiento y ruptura de la conexión, control de flujo, control de errores, etc. No contienen información alguna proveniente del nivel N+1.
Modelo Cliente - Servidor
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
Tipos Cliente - Servidor
Servidores de Impresión
Servidores de Archivos
Servidores de Bases de Datos
Servidores de Lotus Notes
Esquema genérico de un servidor y de un cliente
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.
Abrir el canal de comunicación
Abrir el canal de comunicación
Pedir servicio
Conectar con la dirección del servidor
Comunicar a la red la dirección del canal
fork
Fin del proceso clienteAtender al
cliente
Fin del proceso hijo
Esperar petición de servicio
Esperar respuesta
Proceso servidor Proceso cliente
Ventajas del esquema Cliente/Servidor
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.
Desventajas del esquema Cliente/Servidor
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
7.4.2 Realización de RPC
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.
RPC(continuación)
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.
RPC (continuación)
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.
10 pasos para ejecutar un RPC
10 pasos para ejecutar un RPC
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.
RPC 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.
ONC-RCP(Open Network Computing-Remote Procedure Call)
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.