CAPA DE SESIÓN 7.3 SERVICIOS DE NIVEL SESIÓN 7.4 LLAMADAS A PROCEDIMIENTOS REMOTO (RPC) EQUIPO:

1. CAPA DE SESIÓN 7.3 SERVICIOS DE NIVEL SESIÓN 7.4 LLAMADAS A PROCEDIMIENTOS REMOTO (RPC) EQUIPO: CAB SALINAS ANIBAL JOSÉ FERNÁNDEZ LANDAVERDE VERÓNICA HERNÁNDEZ ÁLVAREZ DAVID ROSAS ZARCO ARIADNA DANAE REDES DE DATOS GRUPO: 02

2. 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.

3. 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

4. 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.

5. 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.

6. PROTOCOLOS IMPORTANTES ADSP, AppleTalk Data StreamProtocol ASP, AppleTalk SessionProtocol H.245, Call Control Protocol for Multimedia Communication ISO-SP, OSI SessionLayerProtocol (X.225, ISO 8327) iSNS, Internet Storage NameService L2F, Layer 2 ForwardingProtocol L2TP, Layer 2 TunnelingProtocol NetBIOS, Network Basic Input Output System PAP, PasswordAuthenticationProtocol PPTP, Point-to-Point Tunneling Protocol RPC, RemoteProcedureCallProtocol RTCP, Real-time Transport Control Protocol SMPP, Short Message Peer-to-Peer SCP, SecureCopyProtocol SSH, Secure Shell ZIP, ZoneInformationProtocol

7. 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

8. 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.

9. 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.

10. 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.

11. 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.

12. 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ó.

13. 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.

14. 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.

15. ORGANIZACIÓN DEL DIÁLOGO CONEXIONES DE SESIÓN / TRANSPORTE Distintas posibilidades: 1.-Una conexión de sesión en una de transporte

16. 2. Varias conexiones de sesión en una de transporte Nota: No se pueden multiplexar varias conexiones simultaneas.

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

18. 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.

19. 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.

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

21. 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.

23. 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.

24. TIPOS DE TESTIGOS: - De datos - De liberación de conexión - De sincronización menor - De sincronización mayor y actividad

25. 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.

26. 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.

27. PRIMITIVAS DE SESIÓN Servicio orientado a conexión

30. SERVICIO SIN CONEXIÓN

31. USO DE LAS PRIMITIVAS DE SESIÓN

33. EVOLUCIÓN DEL PROTOCOLO

34. EVOLUCIÓN DEL PROTOCOLO

35. 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.

36. 7.4 Llamadas a Procedimientos Remoto (RPC)7.4.1 Modelo Cliente – Servidor7.4.2 Realización de RPC

37. 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.

38. 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

39. Tipos Cliente - Servidor • Servidores de Impresión • Servidores de Archivos • Servidores de Bases de Datos • Servidores de Lotus Notes

40. 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.

41. El programa cliente, por su parte, llevara a cabo las siguientes acciones: • 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. • Enviar al servidor un mensaje de petición de servicio y esperar hasta recibir la respuesta. • Cerrar el canal de comunicaciones y terminar la ejecución.

42. 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 Fin del proceso cliente Atender al cliente Fin del proceso hijo

43. 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.

44. 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

45. 7.4.2 Realización de RPC • RPC es un protocolo de SunMicrosystem 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.

46. 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.

47. 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.

49. 10 pasos para ejecutar un RPC

50. 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.