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.

3. Una conexión de sesión en varias de transporte

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.

También pueden extenderse a lo largo de más de una sesión:

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

Servicio orientado a conexión

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

SERVICIO SIN CONEXIÓN

S-UNITDATA Transferencia de datos sin conexión

USO DE LAS PRIMITIVAS DE SESIÓN

EVOLUCIÓN DEL PROTOCOLO

EVOLUCIÓN DEL PROTOCOLO

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.

7.4 Llamadas a Procedimientos Remoto (RPC)

7.4.1 Modelo Cliente – Servidor7.4.2 Realización de RPC

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.

10 pasos para ejecutar un RPC

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.

Ejemplo de aplicación:

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.