CAPA DE SESIÓN
La capa de sesión, presentación y aplicación constituyen las Capas superiores en el Modelo OSI. A diferencia de las 4 capas inferiores, que están involucradas en proporcionar una comunicación de extremo a extremo, en cambio las capas superiores proporcionan una serie de servicios orientados al usuario. Estas parten de un canal sin error, proporcionado por la capa de transporte.
Esta capa es muy delgada, con pocas características, comparada con las capas anteriores. Esta capa no es tan importante como la de transporte, por que muchas aplicaciones no llegan a necesitar de sus características.
La capa de Sesión permite que los usuarios de diferentes maquinas establezcan sesiones entre ellos. Por medio de la Sesión puede llevarse a cabo un transporte de datos ordinario, como lo hace la capa de transporte, pero mejorando el servicio que esta proporciona.
Un servicio de esta capa es el de gestionar el Control de Dialogo. Estas sesiones permiten el trafico en ambas direcciones al mismo tiempo, o a una sola dirección. Si el trafico solo puede ir en una dirección, la capa de sesión ayudara en el seguimiento de quien tiene el turno.
Otro servicio es el de sincronización, aquí la capa proporciona una forma para insertar puntos de verificación en el flujo de datos, con el objeto de que después de cada caída, solamente se repitan los datos que están después del último punto de verificación.
La capa de sesión es la que se ocupa de la administración de la red; tiene la capacidad de cancelar sesiones y controlar la terminación ordenada de una sesión, verifica la contraseña escrita por un usuario y permite que el usuario conmute la transmisión semiduplex (esperar turno ) a dúplex ( en ambas direcciones ).
Puede determinar quien habla, con que frecuencia y durante cuanto tiempo, controla la transferencia de datos e incluso maneja la recuperación de una caída del sistema.
Consiste en proporcionar una manera por medio de la cual los usuarios de la capa de sesión establezcan conexiones llamadas sesiones, y transfiera datos sobre ellas en forma ordenada.
Una sesión se parece a una conexión de transporte, pero no son idénticas; por lo general cuando llega a presentarse una solicitud para que la capa de sesión establezca una sesión, se deberá establecer una conexión de transporte que se encargue de soportar la conexión. Cuando termina la sesión se libera la conexión de transporte.
Cada vez que un agente contesta una llamada, se establece una sesióin con el ordenador principal. Una vez que la llamada se procesa, la sesión se da por terminada, pero lo importante aquí es que no hay necesidad de cargar con el problema de liberar la conexión de transporte subyacente, porque seguramente será necesaria otra vez en unos cuantos segundos.
Formas de correlacionar sesiones sobre conexiones de transporte.
Correlación uno a uno.
Sesiones consecutivas utilizan la misma conexión de transporte.
Una sesión se extiende a múltiples conexiones de transporte.
Considérese el caso de una línea aérea que tiene oficinas de reserva en varias ciudades. Cada oficina tiene agentes con terminales conectados a un miniordenador ubicado en la oficina local.
Los miniordenadores se conectan mediante una red de área extendida a un ordenador principal en el cual se encuentra la base de datos de las reservas.
Cada vez que un agente contesta una llamada se establece una sesión con el ordenador principal.
Una vez que la llamada se procesa la sesión se da por terminada, pero lo importante aquí es que no hay necesidad de cargar con el problema de liberar la conexión de transporte, porque seguramente será necesaria otra vez en unos cuantos segundos.
Es más sencillo por lo tanto permitir que sesiones consecutivas utilicen la misma conexión de transporte.
Se da una tercera forma posible de correlación entre sesiones y conexiones de transporte. En este caso se puede observar una sesión que abarca múltiples conexiones de transporte.
Esto es por si llega a fallar una conexión de transporte ( por cualquier razón ), la capa de sesión puede establecer una nueva conexión de transporte y seguir con la sesión sobre la nueva conexión.
La característica más importante del 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:
Establecimiento
Utilización
Liberación
Liberación abrupta
Liberación ordenada
Es otra de las áreas en las que hay diferencia entre las capas de sesión y transporte, aunque solo levemente. Para establecer una sesión, uno debe especificar la dirección SSAP a la cual se va a conectar. Aunque las normas no indican la forma cómo las direcciones SSAP deben ser construidas, es muy probable que en la practica la dirección de un SSAP constará de una dirección TSAP, más alguna información adicional de identificación.
Otro de los motivos por los cuales el intercambio de datos de sesión difiere del intercambio de datos de transporte, es la cantidad de diferentes tipos 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 tiene ambos tipos y, además, otros dos los datos tipados y los de capacidad.
El hecho de mantener un seguimiento de a quien le corresponde el turno de hablar ( y hacerlo cumplir ) , se denomina administración del diálogo. Y es uno de los servicios que puede ofrecer la capa de sesión en el momento que se le solicite.
Todas las conexiones del modelo OSI son dúplex, es decir, las PDU se pueden mover en ambas direcciones sobre la misma conexión.
Hay varias situaciones en las que el software de capas superiores está estructurado de tal forma que espera que los usuarios tomen su turno.
El modo de operación más natural para el usuario es el de enviar una solicitud al sistema de base de datos y después esperar la respuesta.
El hecho de permitir que los usuarios envíen una segunda o tercera solicitud antes de que la primera haya sido contestada, trae como consecuencia una complicación innecesaria al sistema.
Lógicamente resulta deseable que el sistema funcione en modo dúplex, o bien que le toque el turno de transmitir al usuario o al sistema de base de datos.
La realización de la administración del diálogo se hace mediante el empleo de un testigo de datos.
En el momento en que se establece una sesión, el funcionamiento dúplex es una de las opciones elegibles. Si se selecciona el funcionamiento semiduplex la negociación inicial también determina que extremo poseerá primeramente el testigo. Solamente el usuario que tiene el testigo puede transmitir datos, el otro deberá permanecer en silencio. Una vez que el extremo que posee el testigo haya terminado de hacer su transmisión, se la pasará a su corresponsal por medio de la primitiva S-TOKEN-GIVE.request.
Este servicio pareciera innecesario porque la capa de transporte se diseño para recuperar transparentemente los errores de comunicación, así como fallos de las subredes.
Sin embargo, un estudio mas detallado demuestra que la capa de transporte se ha diseñado para enmascarar los errores de comunicación.
Un ejemplo de los problemas que se presentan es en el proceso de transmisión de mensajes impresos de una compañía a otra. Inicialmente, el usuario se encarga de componer un mensaje usando el CRT (tubos de rayos catódicos) y el teclado. Después, la CPU llama a la compañía a la que se desea entregar el mensaje, establece una sesión y transfiere el mensaje. Si el dispositivo receptor no tiene una unidad de disco para almacenamiento, lo que viene a ser una posibilidad real en las versiones más económicas, los mensajes que llegan deberán imprimirse en tiempo real, a medida que se reciben.
Supóngase que se presenta un problema con la cinta o el papel de la impresora; aun cuando el operador se de cuenta rápidamente del problema, y llegue a oprimir el botón del dispositivo para detener el proceso de impresión, una parte de la información puede perderse. Dado que el mensaje ya se había asentido, el emisor ya no tendrá copia del mismo y, por consiguiente, la transmisión del mensaje fallará.
La solución recae en la capa de sesión. Los usuarios de sesión pueden dividir el texto en páginas, e insertar un punto de sincronización entre cada una de las paginas, 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. Pos supuesto, para hacer posible este proceso, llamado resincronización, el usuario de sesión emisor (no la entidad de sesión), deberá continuar reteniendo los datos durante el tiempo que sea necesario.
Los usuarios de sesión pueden insertar puntos de sincronización en el flujo del mensaje. Cada uno de estos puntos lleva un número de serie.
Otra característica clave de la capa de sesión, estrechamente relacionada con la sincronización, es la administración de actividades. La 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.
Depende del usuario el determinar que es una actividad. Ejemplo, considérese una sesión que se haya establecido con el propósito de transferir varios archivos entre dos ordenadores. Se necesita alguna forma para marcar el lugar en donde termina un archivo y comienza el siguiente. El empleo del carácter ASCII FS (Separador de Archivos) no es la mejor idea, porque si los archivos contienen información binaria, estos caracteres podrían aparecer en los datos y señalar accidentalmente el final de un archivo, cuando no se trataba de esto.
Lo que realmente se necesita es alguna manera de insertar un marcador en el flujo de mensajes, que sea en si mismo diferente de un mensaje de datos. Una manera de alcanzar este objetivo consisten en definir cada transferencia de un archivo como una actividad separada, como se ilustra en la figura 2 en esta figura, el emisor emite una primitiva S-ACTIVITY-START.request, antes de que se inicie la transferencia de cada archivo. Esta primitiva llega al otro extremo como un S-ACTIVITY.indication para marcar el inicio del archivo. Similarmente, después de que se completa la transferencia de cada archivo, la primitiva S-ACTIVITY-END se puede utilizar para marcar el fin del archivo.
Lo único que hace la capa de sesión es asegurar que cuando un usuario haga una solicitud S-ACTIVITY, el otro usuario obtenga la indicación correspondiente. Cuando se hagan estas solicitudes y como reacciones el receptor a las indicaciones, no son cuestiones de interés para la capa de sesión.
Como un ejemplo sobre la manera en que la administración de actividades puede utilizarse, considérese un sistema bancario doméstico en el cual la gente puede pagar sus facturas usando sus ordenadores personales para transferir dinero de sus cuentas a aquéllas de las compañías que emitieron las facturas. El programa que se ejecuta en el ordenador personal podría comenzar preguntando por el número de la cuenta a la que se va a cargar la factura y transmitir esta información al banco en su primer mensaje. Después podría preguntar sucesivamente por el número de la cuenta a la que se va a abonar, así como la cantidad, y enviar estos datos como los mensajes dos y tres.
Otra característica de la capa de sesión es la correspondiente a un mecanismo de propósito general para notificar errores inesperados.
En esta sección se verá con mayor detalle la manera cómo se realizan las RPC. Para tener mayor información al respecto se puede hacer referencia al trabajo realizado por Birrell y Nelson (1984).
En la figura se muestra una manera de realizar un sistema de llamadas de procedimientos remotos. En esta figura, la llamada remota toma diez pasos. El paso 1 consiste en el programa o procedimiento cliente llamando al procedimiento cabo montado dentro de su propio espacio de direcciones. Los parámetros pueden pasarse de la manera normal. El cliente no nota ninguna cosa rara en esta llamada, porque se trata de una llamada normal, de tipo local.
El procedimiento cabo del cliente, entonces, colecta los parámetros y los empaqueta en un mensaje. Esta operación se conoce como encapsulado de parámetros. Después de que el mensaje se haya construido, se pasa a la capa de transporte para su transmisión (paso 2). En un sistema de red tipo LAN sin conexión, la entidad de transporte probablemente sólo unirá una cabecera al mensaje y lo pondrá en la red (paso 3). En una red tipo LAN, la transmisión real puede ser más complicada. En muchos sistemas, el paso 2 es una llamada al sistema operativo.
Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al procedimiento cabo del servidor (paso 4), el cual se encarga de desencapsular los parámetros. El procedimiento cabo del servidor entonces llama al procedimiento servidor (paso 5), pasando los parámetros en la forma normal. El procedimiento servidor no tiene ninguna manera de notar que está siendo activado a remoto, porque el que está haciendo la llamada, es un procedimiento local que obedece todas las reglas normales. Sólo el procedimiento cabo sabe que está sucediendo algo especial.
Después de que haya completado su trabajo, el procedimiento del servidor devuelve el control (paso 6), de la misma manera como cualquier otro procedimiento devuelve el control una vez que termina. También, puede devolver un resultado al extremo que le hace la llamada. El procedimiento cabo del servidor, entonces, encapsula el resultado en un mensaje y lo entrega a la interfase de transporte (paso 7), posiblemente haciendo una llamada al sistema, como sucedió en el paso 2. Después de que la respuesta llega a la máquina del cliente (paso 8), se entrega al procedimiento cabo del cliente (paso 9). Por último, el procedimiento cabo del cliente devuelve el control al extremo que hace la llamada, es decir, al procedimiento cliente. Cualquier valor que devuelva el servidor en el paso 6, es entregado al cliente en el paso 10.
El propósito del mecanismo completo de la figura anterior es:
El ofrecerle al procedimiento cliente la ilusión de que está haciendo una llamada directa al procedimiento servidor remoto. En la medida en que la ilusión sea exitosa y que el cliente no pueda decir que el servidor está remoto, se dice que el mecanismo es transparente. Sin embargo, un estudio más detallado revela que existen algunas dificultades para alcanzar una transparencia completa.
¿Cual es el problema que evita esta transparencia?
El problema principal ocurre durante el proceso de paso de parámetros. En el caso peor, una conversión a un formato normalizado en la red podría ser necesario (capa de presentación).
El problema aparece en el momento en que el lenguaje permite que los parámetros se pasen por referencia, en lugar de por valor. Para el caso de una llamada local, normalmente se pasa un puntero (es decir, la dirección del parámetro) al procedimiento que es llamado; este procedimiento sabe que está tratando con un parámetro pasado por referencia, por tanto puede usar el puntero para acceder el parámetro correspondiente.
Esta estrategia, para el caso de una llamada remota, fracasa completamente. Cuando el compilador produce el código para el servidor, no sabe nada respecto a la RPC, y genera las instrucciones normales para acceder a lo apuntado. Naturalmente que el objeto al que se está apuntando no se encuentra ni siquiera en la máquina del servidor, y aun que estuviera, no tendría la misma dirección ahí que la que tenía en la máquina del cliente. Como resultado de esto, cuando un servidor trata de utilizar un parámetro pasado por referencia, obtiene un valor incorrecto y la ejecución fracasa.
La solución al problema:
Una posible solución a este problema consiste en reemplazar el mecanismo de llamada por referencia por una llamada de copia/reconstruye; mediante la cual el procedimiento cabo del cliente localiza el objeto que se está apuntando y se lo pasa al procedimiento cabo del servidor. Este, a su vez, lo coloca en algún lugar de la memoria y le pasa el puntero correspondiente al procedimiento servidor. Entonces, el servidor es capaz de acceder dicho objeto en forma normal.
Ahora, pasemos del concepto de paso de parámetros a otro aspecto de realización:
¿Cómo llega a saber el procedimiento cabo del cliente a quién llamar?
En redes orientadas a conexión tradicionales, las sesiones se establecen entre los SSAP, cada uno de los cuales tiene un "número de teléfono" fijo. Para el caso de una RCP se necesita un esquema más sencillo, aunque más dinámico.
Birrell y Nelson (1984) describieron un esquema que considera no solamente clientes y servidores, sino también un sistema de base de datos de un tipo más especializado. Cuando se crea un servidor se registra en el sistema de base de datos mediante el envío de un mensaje que contiene su nombre.
Cuando se crea un servidor se registra en el sistema de base de datos mediante el envío de un mensaje que contiene su nombre (como una serie de caracteres ASCII), su dirección de red (por ejemplo, un NSAP, TSAP o SSAP) y un identificador único (por ejemplo, un número entero aleatorio de 32 bits). Este registro se leva a cabo al hacer que el servidor haga una llamada al procedimiento export, que es manejado por el cabo (pasos 1 y 2).
Posteriormente, cuando el cliente hace su primera llamada (paso 3) y su cabo se enfrenta al problema de encontrar al servidor, el cabo envía su nombre, que es también el nombre del servidor, en ASCII, al sistema de base de datos (paso 4). El sistema de base de datos devuelve entonces la dirección de red del servidor y el identificador único (paso 5). A este proceso se le llama Vinculación. De aquí en adelante, el cabo sabe cómo localizar al servidor, por lo que ya no es necesario repetir este proceso en llamadas subsiguientes.
También a diferencia de las llamadas de procedimiento local, las llamadas de procedimientos remotos están sujetas a la pérdida de mensajes, a caídas de servidores y de clientes. Por lo menos hay tres posibles maneras de programar el cabo del cliente para tratar esta situación.
Quedarse colgado eternamente en espera de una respuesta que jamás llegará.
Al término de una temporización generar una excepción o informar al cliente del fallo.
Al término de una temporización retransmitir la solicitud.
El primer planteamiento es similar a lo que sucede cuando un programa llama a un procedimiento local que contiene un lazo infinito. No se utilizan temporizadores localmente y, por lo tanto, el procedimiento jamás regresa. En este caso se requiere de una intervención manual con objeto de aniquilar al programa.
El segundo de los planteamientos enunciados anteriormente para el manejo de las caídas de los servidores, consiste en hacer que el cabo del cliente al término de una temporización genere una excepción (siempre y cuando el lenguaje de programación soporte las excepciones), o que de otra manera notifique que la aparición de un error.
El tercer planteamiento consiste en hacer que el cabo del cliente retransmita la solicitud al término de una temporización. Dado que el servidor re-registrará un nuevo identificador único en el sistema de base de datos después de una caída, la entidad de transporte en la máquina del servidor rechazará la retransmisión cuando vea al identificador único antiguo, ahora inválido.
Como resultado de estos problemas, la semántica exacta de los sistemas de llamada de procedimientos remotos se puede categorizar de diferentes maneras (Nelson, 1981):
Exactamente una vez.
A lo más una vez.
Al menos una vez.
El tipo de semántica que viene a ser la más deseable es exactamente una vez, en donde cada llamada se lleva a cabo exactamente una vez, ni una más ni una menos.
Un segundo tipo de semántica es la correspondiente a lo más una vez. Cuando se utiliza esta forma, el control siempre regresa al que hace la llamada. Si todo se desarrolla de manera correcta, la operación habrá sido ejecutada exactamente una vez.
El tercer tipo de semántica para una RPC es la de al menos una vez. El cabo cliente reintentará una y otra vez, hasta que consiga una respuesta apropiada. Cuando obtenga de nuevo el control, sabrá que la operación se efectuó una o más veces.
Se le llama así al servidor que se encuentra en funcionamiento, y que no tiene ningún padre que lo este esperando.
Manera de tratarlos:
Exterminación
Expiración
Reencarnación
El protocolo de sesión, es muy complejo, debido a la gran cantidad de primitivas de servicio. Además, su complejidad se acentúo todavía mas pon la decisión política de exigir que el protocolo fuera compatible con el protocolo mucho más antiguo del CCITT, el teletex.
Para cada primitiva de servicio, hay un SPDU (unidad de datos del protocolo de sesión) correspondiente, que se trasmite cuando se invoca aquella. Para el caso de las primitivas con respuesta, hay una SPDU que es generada por la respuesta.
Ahora, examinaremos someramente los formatos de las PDU que utiliza el protocolo de sesión. El campo SI (identificador de sesión), consta de un octeto que da el tipo de SPDU.
El campo LI (identificador de longitud), normalmente es un valor que oscila entre 0 y 254, indicando cuantos octetos de parámetros son los que siguen. Si llega a haber más de 254 octetos de parámetros, LI toma el valor de 255, e inmediatamente le siguen dos octetos adicionales, dando la longitud (hasta un máximo de 65535 octetos). Después de los parámetros, vienen los datos del usuario, si los hay.
Muchas primitivas del servicio de la capa de sesión, y por consiguiente sus SPDU, transporta parámetros (por ejemplo, la dirección llamada o él numero de serie de la sincronización). Se proporcionan varios formatos para codificar estos parámetros. Hay un campo PI (identificador del parámetro) de un octeto, indicando cual es el parámetro que sigue, un campo LI (identificador de longitud) de un octeto, indicando la longitud del parámetro y un campo de longitud variable PV (valor del parámetro) que contiene el valor numérico del parámetro.
En otras SPDU, los parámetros pueden asociarse en grupos. Cada grupo comienza con un PGI (identificador de grupo de parámetros), seguido por un campo LI que da la longitud del grupo.
Cuando la entidad de sesión ha construido una SPDU, puede entregarla a la capa de transporte como un mensaje. Sin embargo, en muchos casos, el protocolo de sesión también permite que la entidad de sesión empaquete varias SPDU en un solo mensaje. Esta técnica reduce él numero de primitivas de transporte que deben invocarse; proceso que se conoce normalmente con el nombre de concatenación. Al proceso inverso (es decir, al desempaquetamiento del mensaje que llego, en múltiples SPDU), al trabajo que realiza la entidad de sesión remota, se le denomina separación.
No esta permitido realizar una concatenación entre dos SPDU arbitrarias; existen reglas extrañas para la concatenación. Las SPDU se dividen en tres categorías: las que no pueden concatenarse, las que deben concatenarse, y las que pueden o no concatenarse, a discreción de la entidad de sesión.
Aunque la norma del protocolo de sesión del modelo OSI (la ISO 8327), no indica la forma detallada para realizar el protocolo de sesión, si describe su funcionamiento básico como una gran maquina de estados finitos conocida como SPM (Maquina de protocolo de sesión).
ARPANET no tiene una capa de sesión que se le parezca; si no más bien depende de las aplicaciones individuales al manejo de sus sesiones, siempre que sea necesario. Por otro lado, se ha trabajado mucho sobre RPC dentro de la comunidad de conexión de redes ARPA, especialmente en Xerox PARC y en la universidad de Carnegie-Mellon.
MAP y TOP utilizan una forma restringida de la capa de sesión del modelo OSI. El establecimiento de sesión, la trasferencia de datos y la liberación de sesión están totalmente soportados para el modo dúplex; mientras que el modo simiduplex no esta soportado. El servicio de sincronización, la administración de actividades, la notificación de excepciones, los datos tipados y el servicio de datos de capacidad no son requeridos.
Los protocolos de sesión de MAP Y TOP son de subconjuntos de los protocolos completos de sesión del modelo OSI. Aquellas SPDU necesarias para realizar el subconjunto MAP y TOP deberán ser realizadas. Las demás son opcionales.
Al igual que en ARPANET, USENET no cuenta con una capa de sesión. A diferencia de ARPANET, no es ni siquiera posible, para las capas superiores, realizar por sí mismas los servicios de sesión. Ninguno de los servicios de sesión se necesitan en absoluto.
©Arredondo Hernandez Edy Paul