Intercambio de Datos

La característica mas importante de la capa de sesión es el intercambio de datos. Una sesión, al igual que una conexión de transporte, sigue un proceso de tres fases: la de establecimiento, la de utilización y la de liberación.

Las primitivas que se le proporcionan a la capa de presentación, para el establecimiento, utilización y liberación de sesiones, son muy parecidas a las proporcionadas a la capa de sesión para el establecimiento, uso y liberación de conexiones de transporte. En muchos casos, todo lo que la entidad de sesión tiene que hacer, cuando primitiva es invocada por el usuario de sesión, es invocar la primitiva de transporte correspondiente para que se pueda así realizar el trabajo. En cualquier caso , y a pesar de estas similitudes, existen importantes diferencias entre el intercambio de datos de sesión y el intercambio de datos de transporte. La mas importante de estas diferencias es la forma de liberar las sesiones y las conexiones de transporte.

Las conexiones de transporte se 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 jamas se llegan a perder. También otro de los motivos porque el intercambio de datos de sesión difiere del de transporte, es en la cantidad diferente de datos. La capa de transporte tiene dos flujos de datos que son lógicamente independientes, es decir, los datos normales y los datos acelerados. La capa de sesión , además de estos dos tipos tiene , también, los datos tipados y los de capacidad.

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. La administración del dialogo será uno e los servicio de la capa de sesión y consistirá en mantener un seguimiento de a quien le corresponde el turno de hablar y de hacerlo cumplir. En el momento en el que se inicia una sesión se seleccionara el modo de funcionamiento y ya sea dúplex o semidúplex, la negociación inicial determina quien tendrá primeramente el testigo de datos porque solo el usuario que posee el testigo podrás transmitir mientras el otro se mantendrá en silencio. Cuando termine le pasara el testigo a su interlocutor.

Sincronización

Otro servicio de la capa de sesión es la sincronización, la cual se utiliza para llevar las entidades de sesión de vuelta a un estado conocido, en caso de que haya un error o algún desacuerdo. A primera vista, este servicio parecería innecesario porque la capa de transporte se ha diseñado cuidadosamente para que se pueda recuperar, en forma transparente, de todos los errores de comunicación, así como de fallos de las subredes. Sin embargo la capa de transporte se ha diseñado para enmascarar los errores de comunicación. Esta no se puede recuperar de los errores cometidos en la capa superior.

La solución recae sobre la capa de sesión. Los usuarios de sesión pueden dividir el texto en paginas, e insertar un punto de sincronización entre cada una de ellas. En caso de presentarse un problema, es posible restablecer el estado de la sesión a un punto previo de sincronización, para desde ahí continuar. Por supuesto, para hacer posible este proceso, llamado resincronización, el usuario de sesión emisor deberá continuar reteniendo los datos durante el tiempo que sea necesario.

Existen dos tipos diferentes de puntos de sincronización, el mayor y el menor, cada uno de ellos con sus propias primitivas. Las unidades delimitadas por los puntos de sincronización mayores se llaman unidades de dialogo, y generalmente representan partes de trabajo lógicamente significativas. Cuando se lleva a cabo la transmisión de un libro, por ejemplo, los capítulos podrían estar delimitados por puntos de sincronización mayores.

Administración de Actividades

Otra de las características claves de la capa de sesión, muy relacionada con la sincronización, es la administración de actividades. La idea tras la administración de actividades es la de permitir 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. Es importante indicar que la elección de lo que constituye una actividad la llevan a cabo los usuarios, y no la capa de sesión. Lo único que hace la capa de sesión es asegurar que cuando un usuario haga una solicitud mediante la primitiva S-ACTIVITY, el otro usuario obtenga la indicación correspondiente.

La capa de sesión solo esta interesada en la ejecución de las primitivas, pero no sobre su significado o uso. Las actividades están estrechamente relacionadas con los puntos de sincronización. Cuando se inicia una actividad, los números de serie de los puntos de sincronización vuelven a 1 y se inserta un punto de sincronización mayor. Dentro de una actividad es posible establecer puntos de sincronización adicionales ya sean mayores o menores. Dado que el inicio de una actividad también corresponde a un punto de sincronización mayor, una vez que se inicia una actividad, ya no es posible resincronizar a un punto anterior a aquel correspondiente al inicio de dicha actividad. Es decir , no es posible resincronizar a un punto de sincronización de una actividad previa.

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. Algunos datos del usuario se pueden transferir utilizando esta primitiva. Los datos del usuario, generalmente, explicaran que es lo que sucedió. 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.indication 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. Estas notificaciones contienen un campo que describe la naturaleza de la excepción. La decisión sobre que acción tomar, si hay alguna, dependerá del usuario.