LA CAPA DE APLICACIÓN
La capa de aplicación contiene los programas del usuario (los que también se llaman aplicaciones) que hacen el trabajo real para el cual fueron adquiridas las computadoras.
Estos programas utilizan los servicios que ofrece la capa de presentación para sus necesidades de comunicación. Sin embargo ciertas aplicaciones, como la de transferencia de archivos, son tan comunes que precisamente se han desarrollado normas para eliminar la necesidad de que cada compañía desarrolle la suya propia y, además para asegurar que todos utilicen los mismos protocolos.
La transferencia de archivos y el acceso de archivos remotos, son dos de las aplicaciones más comunes en cualquier red de computadoras. Además de situaciones como las que se dan en las universidades que tienen muchas estaciones de trabajo sin disco, distribuidas en los terrenos de las mismas, junto con una o más máquinas que tienen discos de gran capacidad. Los estudiantes se pueden registrar en cualquier estación de trabajo y acceder sus archivos a través de la red.
El acceso de archivos remotos (como en el caso de las estaciones de trabajo sin unidades de disco) es similar a la transferencia de archivos, con la excepción de que solamente se leen o escriben partes de archivos, en lugar de hacerlo con los archivos completos.
La técnica utilizada para la transferencia de archivos y el acceso de archivos remotos es similar, así como el acceso a un archivo localizado en una computadora remota, que tiene sus propios usuarios, es poco diferente al acceso a un archivo en una máquina dedicada, servidor de archivos, que no tiene usuarios locales.
Por razones de simplicidad, se supondrá que los archivos están localizados en máquinas servidoras de archivos, y los usuarios que quieren transferir, ya sea completos o parcialmente, estos archivos para leer y escribir se encuentran en máquinas clientes.
A diferencia de las capas de sesión y presentación, para las cuales se ha realizado muy poco trabajo de investigación fuera del modelo OSI, se ha hecho mucha investigación sobre la transferencia de archivos en universidades y en la industria, se han construido y se ha experimentado con muchos servidores de archivos y como resultado de esto este documento refleja tanto el trabajo realizado dentro del modelo OSI, como fuera de él.
La idea clave que está detrás de la mayoría de los servidores de archivos modernos es la de un almacén de archivos virtual, que es un servidor de archivos abstracto, operando independientemente o funcionando como un proceso en una computadora de tiempo compartido.
El almacén de archivos virtual presenta a sus clientes una interfase normalizada, y proporciona un juego de operaciones normalizadas que los clientes pueden ejecutar. La transferencia hacia y desde el almacén de archivos virtual utiliza protocolos normalizados. Si el servidor de archivos real tiene una estructura interna diferente a la del almacén de archivos virtual, necesitará de un software en la capa de aplicación, que oculte la realidad a los clientes, y que haga visible, únicamente la interfase del almacén de archivos virtual. Al normalizar una interfase de almacén de archivos virtual particular, como el modelo OSI lo hizo, es posible para los programas de aplicación acceder y transferir archivos remotos, sin llegar a enterarse de todos los detalles de los numerosos servidores de archivos incompatibles.
El CCR(Compromiso, concurrencia y recuperación) es un elemento de servicio que se encarga de coordinar las interacciones de múltiples partes de una manera infalible, aun cuando se presenten fallos de los sistemas en forma repetida.
Lo que se requiere es tener un protocolo que lo logre por completo, o bien, que no haga nada absolutamente en lugar de aquél que sólo realiza una pare del trabajo para después dejar al sistema en uso en un estado inconsistente.
El CCR resuelve el problema de inconsistencia proporcionando acciones atómicas; una acción atómica es una colección de mensajes y operaciones que, o bien tienen un éxito completo o pueden regresar al estado inicial, como si lo hubiera ocurrido ninguna acción.
En la primera fase, el maestro le indica a cada esclavo lo que quiere que se haga. Cada esclavo verifica si puede llevar a cabo su solicitud; si así fuera, entonces procede a registrar la solicitud en un almacén estable, para después bloquear los datos de tal forma que ninguna solicitud, procedente de otros maestros, pueda llegar a interferir y, finalmente, devuelve el informe sobre su éxito. En el almacén estable, también registra el estado inicial de los datos.
Por otra parte, si un esclavo no puede ejecutar la solicitud, sólo devuelve inmediatamente una notificación sobre el fallo y no hace nada más.
Una vez que hayan devuelto todas las respuestas, el maestro mira si todos los esclavos pueden ejecutar las tareas asignadas. Si es así, le envía a cada uno de ellos un mensaje de compromiso, mediante el cual se les instruye que sigan adelante y realicen la tarea asignada. Debido a que la perdida de mensajes se maneja en las capas inferiores, la única cosa que puede estar incorrecta es que el esclavo tanga un fallo antes de que realice su tarea. Sin embargo, se puede recuperar en el momento en que se reactive buscando en el almacén estable cuál era el estado inicial que tenia que se suponía tenia que hacer.
Si alguno de los esclavos notifica la aparición de un fallo en la primera fase, el maestro abortará la acción y les indica a todos los esclavos que desbloqueen a sus datos y restablezcan el estado inicial. El resultado neto es que no se llega a hacer ningún trabajo y los datos no se modifican.
El manejo de archivos es uno de los principales servicios en cualquier red o sistema distribuido.
Un servidor de archivos (o un almacén de archivos virtual) puede ser caracterizado por las siguientes tres propiedades:
1. Estructura de los archivos
Todos los servidores de archivos tienen un modelo conceptual de lo que significa un archivo. Diferentes servidores de archivos tienen diferentes modelos. Sin embargo, tres son los modelos que se utilizan más ampliamente:
En el primer modelo, un archivo es un conjunto no estructurado de datos, sin ninguna subestructura conocida para el servidor de archivos. Dado que el servidor de archivos no sabe nada sobre la estructura interna de sus archivos, no puede ejecutar ninguna operación en ninguna parte de los archivos. Típicamente, las únicas operaciones posibles en este modelo son la lectura y escritura de los archivos enteros.
El siguiente paso es el archivo plano, el cual está constituido por una secuencia ordenada de registros. Por medio de estos archivos, es posible que los clientes direccionen registros específicos, ya sea por sus etiquetas o sus posiciones, de tal forma que el servidor de archivos puede soportar operaciones en registros individuales, como su extensión, reemplazo o eliminación.
El modelo más general de un archivo es el archivo jerárquico, que toma la forma de un árbol. Cada nodo del árbol puede tener una etiqueta, un registro de datos, ambos o ninguno. Con frecuencia resulta muy útil tener una norma de ordenamiento para todos los nodos, no sólo para permitir que los nodos sin etiqueta sean direccionados mediante la posición del nodo, para ejecutar las operaciones de eliminación y reemplazo, sino también para la transferencia de archivos completos.
Todos los archivos tienen atributos que los describen. Como mínimo, cada archivo debe tener un nombre o algún otro identificador, así como un tamaño indicando la cantidad de espacio que realmente está ocupando.
Algunos atributos son creados cuando se crea el archivo, y de ahí en adelante se congelan. Otros se pueden modificar explícitamente mediante operaciones del usuario.
Las operaciones sobre los archivos se pueden aplicar a un archivo como un todo o a su contenido; es decir, a los registros individuales. Un archivo, por ejemplo, puede ser creado con autorización para leerlo, pero sin autorización para insertar, reemplazar, extender o borrar ninguno de sus registros. Así, el archivo no puede ser modificado después de haberse creado.
Algunos de los servidores de archivos también soportan las operaciones de directorio. Los clientes pueden crear y borrar directorios, así como mover archivos de un directorio a otro. Todos los servidores de archivos deben ocuparse, de alguna manera, del control de acceso y protección. La manera más simple y menos fiable consiste en suponer que todas las máquinas clientes son fiables y llevar a cabo todas las solicitudes que llegan.
Si todas las máquinas clientes son computadoras grandes, con esquemas de protección elaborados que impiden que los usuarios hagan inclusive solicitudes no autorizadas a los servidores, entonces se puede justificar esta propuesta.
En una red pública X.25 de área extendida, la dirección del que llama proporcionada por el operador durante el establecimiento de conexión, puede ser suficiente para autentificar al que llama como una computadora grande segura. Por otra parte, confiar en computadoras personales en una red tipo LAN es muy arriesgado, por lo que es más conveniente buscar un método mejor para ese caso.
Uno de estos métodos es el de verificar el emisor de cada solicitud, ya sea haciendo que éste incluya una contraseña secreta en cada una de las solicitudes o con algún otro método.
Una vez que el servidor conoce la identidad del cliente, puede utilizar cualquiera de los esquemas tradicionales, empleados como protección por sistemas de tiempo compartido. Por ejemplo, el dueño podría designar los derechos de acceso para sí mismo, o para otros miembros de su grupo o para otras personas, o bien, para cada archivo podría dar una lista en la que aparecieran sólo aquellos que pueden accederlo.
Un método más elaborado consiste en tener una o más contraseñas secretas por archivo (por ejemplo, una para lectura y otra para escritura), en este sistema, a cualquiera que presente una contraseña válida se le permitirá la ejecución de las operaciones correspondientes, sin que importe la verdadera identidad del emisor.
Los servidores de archivos de una red tienen que ocuparse de múltiples clientes. Si sucediera accidentalmente que dos o más clientes decidiesen acceder el mismo archivo, más o menos al mismo tiempo, pueden ocurrir problemas.
Una solución realizada extensamente es aquella que permite que los clientes pongan candados a sus archivos antes de utilizarlos. Se utilizan dos tipos de candados, el candado compartido y el candado exclusivo. Cuando un cliente solicita un candado compartido sobre un archivo, típicamente en el momento en el cual se abre el archivo, el candado se asignará sólo si el archivo no tiene otro candado o tiene otros candados compartidos sobre él. Si tiene un candado exclusivo, la solicitud de apertura no puede satisfacerse. Los candados exclusivos, por lo tanto, sólo se asignan a archivos que no tengan ya otro candado.
Los candados compartidos, se utilizan para lectura; en tanto que los candados exclusivos por lo general se utilizan para escritura.
Para no rechazar las solicitudes de candados exclusivos que pueden otorgarse, el servidor podría ponerlas en una cola de espera, de la misma forma, poner en otra cola de espera a las nuevas solicitudes de candados compartidos.
Es posible poner candados sobre archivos enteros, pero también es factible hacerlo sobre registros específicos o subárboles.
Si dos clientes necesitan actualizar el mismo archivo, no hay razón para impedir que lo hagan en forma simultánea, si están trabajando en diferentes subárboles que pueden tener candados independientes.
Los candados, sin embargo, introducen varios problemas molestos.
1. Si un cliente necesita acceder varios archivos, que es el caso más común en el proceso de transferencia de dinero en aplicaciones bancarias, existe un bloqueo muto potencial. Si el cliente 1 tiene un candado en el archivo A y el cliente 2 tiene un candado en el archivo B, y cada uno está tratando de obtener el otro archivo, ninguno de los dos tendrá éxito. En algunas ocasiones son posibles soluciones especificas como aquellas en las que se les permita a los clientes poner candados sobre los archivos en orden alfabético, evitando así los ciclos, pero en general, el evitar que se presente un bloqueo mutuo dependerá de los clientes y no del servidor de archivo.
2. ¿Qué sucede con un cliente que se cae en el momento en que retiene varios candados? Los archivos que tienen un candado permanecerán así para siempre, a menos que se haga algo al respecto. Si al servidor no se le mantiene informado sobre las caídas de los clientes, la única cosa que puede hacer es adoptar una norma en la que automáticamente ser rompan todos los candados que actúan sobre los archivos que no se han accedido durante un intervalo de tiempo especificado. Sin embargo si un cliente es demasiado lento, puede descubrir que algunos de sus candados se rompieron al término de una temporización en algún momento de una complicada actualización de múltiples archivos provocando un caos.
En lugar de hacer que los clientes fijen sus candados individuales, algunos servidores de archivos soportan acciones atómicas, a las que frecuentemente se les conoce como transacciones, en el contexto de los servidores de archivos. Cuando se tiene a disposición este tipo de servicio, un cliente puede indicarle al servidor que comience una transacción, seguida por cualquier número de aperturas y operaciones sobre los archivos y terminada con un comando, indicando que llegó el fin de la transacción. Dependerá directamente del servidor el hecho de llevar a cabo todas las solicitudes de una manera atómica (es decir, indivisible), sin ningún tipo de interferencia ocasionada por las solicitudes de otros clientes. Si un cliente decide abortar la transacción, o si vence un plazo o si llega a surgir algún contratiempo, todos los archivos se vuelven a restaurar al estado que tenían, antes de3 que se iniciara la transacción.
Las transacciones se pueden realizar haciendo que el servidor haga una copia de cada uno de los archivos que abre para escritura. Los cambios que se hacen por escrituras subsiguientes se realizan en la copia, y no en el original. Si la transacción se lleva a cabo conexito, las copias reemplazan a los originales. Las técnicas CCR, pueden utilizarse siempre y cuando estén involucrados múltiples servidores.
Si dos clientes utilizan el mismo archivo en transacciones simultaneas, el primero que termina es el que gana y realiza todos los cambios, mientras que el segundo de ellos se aborta. Aunque esta estrategia significa que el segundo cliente ha desperdiciado tiempo de CPU, éste efectivamente es devuelto al inicio de su transacción, por lo que no se ha hecho daño alguno en ninguno de sus archivos. Es como si este cliente jamás hubiera comenzado.
Lo interesante del modelo de transacciones reside en el hecho de que no hay candados visibles de usuarios y el servidor puede evitar los bloqueos.
Un planteamiento completamente diferente consiste en evitar todas las actualizaciones. Desde este punto de vista, los archivos son inmutables; es decir, una vez que se haya creado un archivo, jamás se podrá cambiar.
Para permitir que se incorpore nueva información en un archivo, un cliente puede crear una nueva versión de un archivo, la cual reemplaza (pero no modifica al original.) Un archivo por consiguiente, se convierte en una secuencia de versiones inmutables. Cuando un cliente abre un archivo, se abre la versión más reciente.
Dado que la creación de una nueva versión es una operación atómica, no hay problemas con archivos que contienen actualizaciones de múltiples clientes.
Veamos ahora los sistemas con múltiples servidores y múltiples clientes. Las redes tienen frecuentemente múltiples servidores de archivos por varias razones:
1. Para dividir la carga de trabajo entre múltiples servidores.
2. Para permitir que se tanga acceso a archivos aun cuando un servidor de archivos esté inactivo.
3. Para incrementar la fiabilidad al tener respaldos independientes de cada archivo.
Una estrategia para la replicación de archivos consiste en dejar que cada usuario abra cuentas con tantos servidores de archivos como crea necesario, y maneje él mismo todas las réplicas.
Esto hace que el usuario tenga una carga administrativa considerable y, siendo la naturaleza humana lo que es, no se puede esperar mucha replicación. Sin embargo, cuando la caída de un servidor destruye los archivos de un usuario, las declaraciones, ante esto, procedentes de la administración central de la computadora, como es culpa tuya, es probable que no sean muy bien recibidas.
Por lo tanto, preferiríamos que los mismos servidores de archivos hicieran la replicación automáticamente. Es fácil mantener copias múltiples, mientras los archivos no se lleguen a modificar. El problema surge cuando se actualiza una copia: las otras también se deberán actualizar. La solución más sencilla, y que se emplea extensamente en la práctica, es la del replicado de la copia principal. En este esquema, una copia se designa como maestra y todas las demás como esclavas. Las actualizaciones siempre se efectúan en la maestra, la cual entonces se difunde hacia.
Aunque este método es sencillo y no tiene ambigüedad, presenta la gran desventaja de hacer que las actualizaciones sean imposibles en el momento en que la maestra no esta disponible, ya sea debido a una caída de su servidor o a la partición de la red (por ejemplo, debido a la indisponibilidad de una pasarela).
Un método más robusto, especialmente con múltiples clientes que se encuentran activos es el del voto (Gifford, 1979). Sea N él numero de servidores con copias de un archivo. Para leer un archivo, se necesita obtener un quórum de lectura, N para modificar un archivo, uno necesita un quórum de escritura, N sujeto a la restricción N + N > N. Solo después de haber preguntado a un numero apropiado de servidores respecto a sí están interesados en participar y aceptan, se puede efectuar la operación.
El punto sobre la necesidad de tener quórum se puede ver mediante un ejemplo. Supóngase que un cliente adquirió dos servidores para lectura, A y B. Para que otro cliente pueda realizar una actualización, deberá adquirir un quórum de escritura constituido por ocho servidores, lo cual es imposible, dado que solo hay nueve de ellos, y dos ya se encuentran ocupados. Los escritores potenciales deberán esperar hasta que el lector haya terminado. (Como punto aparte, el lector no necesita leer las copias de cada servidor, pues una copia es mas que suficiente).
Dado que las escrituras no actualizan todas las copias del archivo, un quórum de lectura en general contendrá algunas copias obsoletas, así como la ultima de ellas. Para permitir que los lectores sepan cual es la mas recientemente, cada una de las copias deberá mantener un número de versión. Cada escritura crea una nueva versión, con un numero mayor que el de cualquier versión anterior, de tal forma que cuando un lector consiga un quórum, podrá saber que copia o copias están actualizadas (siempre habrá por los menos una).
Una variante interesante del voto es el voto con fantasmas (Van Renesse y Tanenbaumn, 1988). En la mayoría de las aplicaciones las lecturas son mucho más frecuentes que las escrituras, por lo que N normalmente es un número pequeño y N es casi N. Esa elección significa que si algunos servidores están inactivos, será casi imposible obtener un quórum de escritura.
El voto con fantasmas resuelve este problema al crear un servidor de relleno, sin almacenamiento, para cada uno de los servidores reales que están inactivos. Un fantasma no esta permitido en un quórum de lectura (después de todo, no tiene ningún archivo), pero puede unirse a un quórum de escritura, en cuyo caso sencillamente desechará el archivo que se escribió para él.
Cuando un servidor que falla se restablece, deberá obtener quórum de lectura para localizar la versión mas reciente, la que entonces copia para el mismo, antes de comenzar a operar normalmente.
Los servidores de archivos son tan importantes y útiles, que es importante hablar un poco acerca de cómo se realizan. La manera más sencilla es la de organizar el servidor como único proceso. Las solicitudes de trabajo llegan, se procesan y los resultados se envían de regreso. El servidor trata una solicitud a la vez mientras se encuentra ocupado con la solicitud actual, todas las demás solicitudes se ponen simplemente en una cola de espera, hasta que el servidor este disponible.
El planteamiento es efectivamente utilizable pero tiene la desventaja de que, si el procesamiento de una solicitud llega a necesitar varios accesos a discos, el servidor está inactivo mientras espera que se complete los accesos a disco. Un diseño mas sofisticado es cuando el servidor de archivos se divide en varias tareas que comparten un espacio de direcciones común. Las tareas comparten datos globales como tampones y tablas del sistema de archivos.
Cuando llega un mensaje de solicitud, procedente de un cliente, el núcleo lo acepta y lo pasa a la tarea despachadora que normalmente esta en espera, ésta lo revisa y lo entrega a una tarea trabajadora inactiva.
Cada tarea maneja una solicitud hasta que se llega a completar. Sin embargo, si una tarea se bloquea mientras se está esperando por el disco, se puede ejecutar otra tarea. De esta forma, el CPU nunca se encuentra inactivo mientras haya trabajo por realizar.
La mayoría de los servidores de archivos están orientados a bloques, es decir dividen el disco en bloques y representan a los archivos como secuencia de estos.
Una técnica muy utilizada para mejorar el rendimiento consiste en hacer que el servidor mantenga un tampón caché en memoria el cual esta constituido por los N bloques mas recientemente utilizados. Si el tampón es suficientemente grande el éxito puede ser del 90%.
En el sistema Amoeba se sigue un planteamiento diferente, no esta orientado a bloques; en lugar de esto, cada archivo se almacena en forma continua; este sistema puede funcionar muy próximo al ancho de banda completo de una LAN subyacente.
Aunque el tampón caché de una maquina servidora logra mejorar el rendimiento es mejor tener un tampón en las maquinas clientes en su lugar o además del tampón caché del servidor. El tampón de los clientes puede estar en disco o en memoria.
Cuando los archivos se comparten entre múltiples usuarios trabajando en diferentes maquinas el tampón provoca un problema. Si un usuario en una de estas maquinas modifica la copia local, los cambios no serán visibles para las otras maquinas. Por lo cual la semántica de la distribución del archivo se altera.
Una solución es hacer que el servidor de archivos mantenga un seguimiento sobre los bloques y archivos que cada cliente tiene en su tampón caché. Cada vez que un cliente modifique un bloque o archivo se lo comunicará al servidor.
En el mundo de las conexiones en red hay una polémica muy grande sobre el problema de servidores de archivo orientados a conexión y sin conexión. En el modelo de un sistema sin conexión se tiene un servidor de archivo sin estado, el cliente envía una solicitud especificando el archivo, la posición del registro o etiqueta, así como la cantidad de datos que se van a transferir.
El servidor orientado a conexión mantiene su estado interno. Cuando un archivo se abre, el servidor genera una entrada en una tabla para el archivo recientemente abierto.
En el modelo sin estado, el cliente es el que se encarga de mantener la posición dentro del archivo y transmitirla junto con cada una de las solicitudes. En el otro modelo el servidor es el que se encarga de hacer el seguimiento de la posición dentro del archivo.
Cada modelo tiene sus ventajas; en el primero su robustez. Si llega a tener una caída y después se reactiva, no hay ninguna información de estado que se pueda perder, aunque resulta muy difícil implementar la semántica normal de un sistema de archivos con una forma sin estado.
El correo electrónico ha estado presente durante las ultimas dos décadas a medida que transcurrió el tiempo. Sus limitaciones llegaron a ser más notorias:
1. - Resultaba laborioso transmitir un mensaje a un grupo de personas.
2. - Los mensajes no tenían una estructura interna.
3. - El emisor nunca podía saber si el mensaje llegó o no.
4. - Si alguien planeaba estar ausente no podía transferir su cuenta.
5. - La interfase de usuario estaba débilmente integrada con el sistema de transmisión.
6. - No era posible transmitir mensajes mezclados.
En esta sección proporcionaremos un resumen sobre lo que los sistemas de correo electrónico pueden hacer y como están organizados. El MOTIS se ocupa de todos los aspectos del sistema de correo electrónico. Comenzando desde el instante en el que el extremo de origen decide escribir un mensaje, y terminando en el instante en que el extremo receptor lo tira a la basura. Enseguida mencionamos 6 de los aspectos básicos de cualquier sistema de correo electrónico:
Composición
Transferencia
Notificar
Conversión
Formateo
Disposición
Además de estos servicios básicos la mayoría de los sistemas proporcionan una gran variedad de características avanzadas. La mayoría de los sistemas de correo permiten crear buzones para guardar el correo que le llega, permiten la utilización de lista de distribución, que viene a hacer una lista de direcciones de correo electrónico; el correo certificado permite al emisor saber que su mensaje llegó a su destino. Otras características son los destinatarios con copias, el correo de alta prioridad, el correo secreto y los receptores alternativos.
Por lo general los sistemas de correo distinguen 3 tipos de mensajes: Mensajes de usuario, notificaciones y ondas de prueba.
Los mensajes de usuario contienen información que se transmite desde un usuario hasta otro.
Las notificaciones son mensajes generados por el sistema, que vuelven al origen para informa si un mensaje fue o no realmente entregado.
Las ondas de prueba son mensajes especialmente constituidos por sobres vacíos.
El agente usuario es un programa que proporciona la interfase para el sistema de correo; el cual le permite al usuario la redacción, envió y recepción de correo así como manipular los buzones.
El agente de transferencia de mensajes acepta el correo de los agentes usuarios y se encarga de que inicie su camino. El agente de transferencia de mensajes es la oficina de correo electrónicos.
A la colección de todos los agentes de transferencias de mensajes se le llama sistema de transferencia de mensaje. A este sistema se le subdivide en dominios administrativos.
El sistema de correo electrónico esta dividido en dos partes básicas: los agentes usuarios y los agentes de transferencia de mensajes.
El agente de usuario detiene tres clases diferentes de interacciones: maneja el diálogo con el usuario, en el terminal; se comunica con el sistema de transferencia de los mensajes, con la aceptación y entrega de mensajes y; se relaciona con el almacén de mensajes.
Como un ejemplo del modo de funcionamiento de un agente de usuario, echemos un vistazo a una escena típica de correo. Después de iniciar el programa de correo, el usuario solicita ver los mensajes del buzón utilizado para la entrada de correspondencia. En un sistema mas sofisticado, el usuario puede especificar que campos quiere que se visualice en la pantalla, proporcionando un perfil del usuario.
Pasemos ahora de la interfase del usuario al protocolo utilizado entre dos agentes de usuario; en gran medida este protocolo esta definido por los campos de cabecera que se incluyen en cada mensaje.
Aunque el cuerpo del mensaje no este tan fuertemente estructurado como la cabecera, sin embargo, si tiene una estructura. El cuerpo consiste de una parte principal y, opcionalmente, de uno o dos agregados.
Originador
El sistema de transferencia de mensajes se ocupa de la transferencia del mensaje desde la persona que lo origina hasta el receptor. Con el sistema de correo, se le puede enviar un mensaje a alguien, aún cuando esta persona se encuentre de vacaciones, o bien que su agente de usuario no se encuentre actualmente registrado. El correo electrónico está, por lo tanto, modelado de acuerdo a un sistema de almacenamiento y reenvío que opera de salto en salto y no de extremo a extremo.
Cuando llega un mensaje al agente de transferencia de mensajes, el proceso se desarrolla aproximadamente de la manera que sigue. Si el mensaje procede de un agente de usuario, se coteja la validez de la sintaxis y, si ésta aparece inválida, se devuelve el mensaje con una explicación. Si la sintaxis es válida, se adhiere al mensaje un identificador de mensaje y un sello de tiempo y, después, se le da el mismo tratamiento que el de un mensaje que proviene de otro agente de transferencia de mensajes.
El siguiente paso consiste en averiguar si el agente de usuario receptor, o el buzón receptor, son locales. Si así fuera, se podrá entregar el mensaje, o ponerlo en cola de espera para su entrega, o bien almacenarlo en el buzón. Cuando se requiera, se puede generar una notificación para confirmar la entrega, y enviarlo de regreso. Si el receptor no es local, el mensaje se retransmite a otro agente de transferencia de mensajes. La correspondencia internacional podría tener necesidad de transitar a través de una pasarela de acceso en cada frontera nacional.
En la mayoría de los sistemas, se inserta una relación de los agentes de transferencia de mensajes que han estado manejando el mensaje. Esto, no sólo facilita seguir la pista de los problemas que hayan ocurrido, sino que también permite detectar si ha habido lazos. Si un agente de transferencia de mensajes recibe un mensaje en cuya relación se encuentra él mismo, sabrá que el mensaje está dando vueltas en un lazo y tendrá que aplicar medidas especiales para romper dicho lazo. Realizar una entrega a un agente de usuario local no es siempre algo trivial, dado que la persona que envía y el receptor pueden tener distintos tipos de equipos. Algunos de los tipos de mensaje posibles son los siguientes:
· Texto ASCII
Si el receptor está incapacitado para aceptar directamente el tipo de mensaje, el agente de transferencia de mensajes puede intentar hacerle una conversión, antes de entregarlo; aunque no todas las conversiones pueden realizarse. Si la conversión no puede efectuarse, tampoco se podrá entregar el mensaje.
Aún cuando la ISO no haya normalizado todos los detalles de la operación de almacenamiento y reenvío entre dos agentes de transferencia de mensajes, sin embargo, ha adoptado la estructura general del CCITT para lo que se ha llamado el servicio de operaciones remotas, la cual está incluida dentro del sistema de correo. Cuatro operaciones han sido normalizadas:
1. Invocar una operación remota en otro ordenador.
Uno de los aspectos clave para el diseño de los agentes de transferencia de mensajes es el del direccionamiento. El CCITT diseñó su propio esquema de direccionamiento.
El último aspecto de transferencia de mensajes es el del sobre. Algunos de los campos se presentan en el siguiente cuadro, y quedan agrupados en cuatro grupos aproximados: direccionamiento, entrega, conversión y seguridad.
CAMPO DESCRIPCION
La necesidad de tener la dirección del originador y la dirección del receptor es bastante obvia. Los dos campos siguientes se ocupan de la posibilidad de entregar el mensaje a la máquina destinataria, pero no al receptor. Si el mensaje es confidencial, la persona que lo emite puede colocar FALSO en el campo receptor alternativo permitido, con lo cual no se le remitirá al "administrador de correos". También es posible especificar un segundo receptor alternativo.
El segundo grupo se ocupa de la entrega. Los dos primeros campos se explican por sí solos. La solicitud de notificación del originador permite que, la persona que origina el mensaje, especifique que deberán devolverle una notificación, si el mensaje fue recibido, si no fue recibido, ambos casos o nunca. La notificación deberá especificar a quién se le entregó realmente (al receptor, al receptor alternativo, al administrador de correos, o a otra persona) y cuándo ocurrió esto. La solicitud de notificación del MTA permite que el agente de transferencia de mensajes, solicite una notificación propia la cual es distinta de la notificación del usuario; puede ser más detallada. El campo de entrega diferida indica el momento a partir del cual el mensaje puede ser entregado. En caso de que el mensaje llegara realmente antes de tiempo, deberá ser retenido. La situación contraria se presenta cuando la entrega, después de cierto límite de tiempo, ya no tenga sentido hacerla. Este límite de tiempo se indica mediante el campo de fecha límite de entrega. El campo de devolución de contenido se activa para asegurar que la totalidad del mensaje será devuelto. Esta característica es muy útil para la gente que envía mucha correspondencia, sin conservar ninguna copia de ella, permitiéndole saber de qué se trataba, cuando el mensaje vuelve por no haberse podido entregar.
El tercer grupo se encarga de realizar la conversión entre textos en ASCII, teletex, facsímil, voz digitalizada y otros tipos de información. En caso de que el receptor llegase a tener equipo inadecuado, a menudo se podrá realizar una conversión. Sin embargo, las conversiones pueden acarrear una pérdida de información, por ejemplo que algunos símbolos sofisticados sean sustituidos por signos de interrogación o, simplemente ser olvidados. Esta serie de campos le permiten tener cierto control sobre el proceso de conversión al extremo de origen y le permiten indicar si realizar una conversión imprecisa es mejor que no entregar ninguna información.
El último grupo se ocupa de la seguridad, proporcionando un cifrado de mensajes, el código de redundancia del contenido (para permitir la detección de mensajes falsificados), la firma digital del emisor (para impedir que los originadores repudien sus propios mensajes), códigos de seguridad y la firma digital del receptor (para impedir que los receptores repudien la entrega). Estos campos proporcionan un espacio normalizado para poner la información.
Las terminales se distribuyen en tres clases principales: los del modo deslizamiento, los del modo página y los del modo formulario.
Terminales del modo deslizamiento
Las terminales de modo deslizamiento carecen de microprocesadores internos y de cualquier posibilidad de edición. Cuando se oprime una tecla, el carater correspondiente se envía a través de la línea ( y también sale posiblemente en la pantalla) y, en el momento que llega un carater, proveniente de la línea, simplemente sale en pantalla. A medida que van apareciendo nuevas líneas, las más antiguas se deslizan hacia arriba. La mayoría de las terminales de salida impresa son de este tipo.
Debido al hecho de que estas terminales carecen de cualquier capacidad de procesamiento, no tienen ninguna posibilidad de comunicarse con la red, a través de algunos de los protocolos normalizados de red que existen. Para solucionar esta carencia, los usuarios adquieren normalmente una "caja negra", que se intercala entre el terminal y la red. La caja negra se comunica con el terminal mediante el RS-232, y con la red mediante un protocolo normalizado. A esta caja negra se le conoce generalmente con el nombre de PAD (ensamblador-desensamblador de paquetes), que también puede realizar algunas conversiones.
Terminales de modo página
Los terminales de modo página son terminales CRT típicos, que pueden visualizar 25 renglones de 80 caracteres cada uno. El ordenador puede mover al cursor sobre la pantalla, para modificar porciones seleccionadas de la página. Todos estos terminales tienen los mismo problemas que los terminales del modo deslizante, además de algunos adicionales, como son: la longitud de página, el direccionamiento del cursor, y la presencia o ausencia de parpadeo, de video inverso, de color y de múltiples intensidades.
Ningún terminal tiene las mismas secuencias de escape para poder utilizar correctamente todas estas características sofisticadas. Esto hace que los editores de pantalla (y otros software orientados a pantalla) sean bastante difíciles. Una solución ampliamente utilizada, iniciada con el UNIX de Berkeley, consiste en definir una terminal virtual, que posea los comandos que tienen la mayoría de las terminales del modo página.
En el momento que un editor inicia su operación, averigua cuál es el tipo de terminal y, después lee la entrada del terminal, de una base de datos llamada termcap (capacidades del terminal). Esta entrada proporciona las secuencias de escape necesarias para cada comando virtual. Siempre que el software se restrinja a producir comandos de terminal virtual, podrá correr sobre cualquier terminal que posea una entrada en termcap.
Terminales del modo formulario
Los terminales más sofisticados son los que tienen microprocesadores dentro. En las aplicaciones, tales como las transacciones bancarias y las reservas en líneas aéreas, el ordenador está capacitado para presentar un formulario (o formato) en la pantalla del terminal, con algunos campos de información, para ser sólo leídos, y otros campos, para ser llenados mediante el teclado. El microprocesador puede suministrar una edición local, unas macros y algunas otras características. A estos terminales se les conoce como terminales del modo formulario.
Después de llenar el formulario, el microprocesador es capaz de correr el programa de comprobación rápida de sintaxis. Cuando el formulario sea sintácticamente correcto, se podrá cargar la porción modificada hacia el ordenador, a través de la red. Obviamente el modelo de termcap no es adecuado para este tipo de aplicaciones y se necesitará contar con un modelo de terminal virtual radicalmente distinto.
Un modelo alternativo bastante adecuado para llevar a cabo las aplicaciones orientadas a pantalla de tipo sofisticado, se basa en la utilización de estructuras de datos compartidas. En este modelo, el software del terminal virtual conserva internamente una representación abstracta de la imagen de la pantalla. Esta representación puede ser leída y actualizada, tanto por el usuario del terminal, como por el programa de aplicación que opera en alguna parte de la red. El software del terminal virtual tiene la responsabilidad de garantizar que sea actualizada la imagen de la pantalla, cada vez que se modifique su representación abstracta.
Para impedir que ambos extremos traten de modificar la estructura de datos simultáneamente, se utiliza un testigo para controlar el acceso de actualización. Tanto el ordenador como el terminal pueden poseer el testigo, pero sólo aquél que lo posea podrá actualizar la estructura de datos. Los testigos pueden ser solicitados y pasados de uno a otro lado, de manera similar a la de los testigos en la capa de sesión, aunque el testigo del terminal virtual no tenga ninguna relación con los testigos allí mencionados.
Una de las consecuencias provocadas por el uso de un testigo, para controlar el acceso a la estructura de datos, es que el usuario del terminal sólo podrá escribir en el teclado cuando el microprocesador posea dicho testigo.
Cuando se propuso por primera vez este modelo síncrono, no todos los usuarios respondieron favorablemente y no pasó mucho tiempo antes de que se propusiera un modelo alternativo, es decir, el modelo asíncrono, mostrado en la figura 10.1b. El modelo asíncrono está constituido por dos monólogos independientes, en lugar de un diálogo único. Cada extremo de la conexión posee una estructura de datos de entrada, y una segunda para la salida. Al modificar la estructura de datos de salida propia, se afecta la estructura de datos de entrada del corresponsal, pero no se afecta la propia estructura de datos de entrada, ni la de salida del corresponsal.
En el modelo asíncrono, cada copia de la estructura de datos tiene un solo lector y un solo escritor, de tal manera que no puedan ocurrir conflictos por escritura simultánea. El costo de esto consiste en almacenamiento adicional y una mayor complejidad, aunque esto quede parcialmente mitigado al no necesitar ningún testigo.
En general, las definiciones de los terminales virtuales no especifican cuándo debes transmitirse las actualizaciones al otro extremo. Sería totalmente ineficiente transmitir cada caracter, escrito en el terminal, como una PDU independiente, aún cuando existan algunas aplicaciones que así lo exigen. En la mayoría de los casos es preferible captar una línea o un campo completo y transmitir una PDU al final. En circunstancias normales, basta con transmitir el resultado neto de toda la escritura, es decir, la línea o campo corregido, son datos erróneos, ni retrocesos o correcciones.
Muchos protocolos de terminal virtual le ofrecen, a cada extremo, la posibilidad de expedir cualquier secuencia legal de comandos, que obtiene el mismo resultado neto que los comandos realmente tecleados. A esta optimización se le llama efecto neto.
El control de entrega es la cantidad de tiempo durante el cual el microprocesador deberá estar colectando golpes de teclado antes de transmitirlos, o de transmitir su efecto neto. Cuanto mayor sea la colecta, mayor será la posibilidad de lograr una optimización, sin embargo, si la decisión fuera la de colectar varias líneas y cada línea fuera un comando para que el ordenador realizara una operación, entonces el usuario del terminal se sorprendería al observar que no sucede nada, después de escribir la primera línea, debido a que nada ha sido enviado.
Los modelos de terminal virtual soportan varios tipos de control de entrega. En el modelo más sencillo, el mismo software de terminal virtual es el que decide cuánto debe almacenar temporalmente y cuándo deberá expedirlo. Se logra un control de entrega más sofisticado mediante un comando primitivo, llamada FLUSH (vaciar), que expide la información de entrada acumulada; ningún dato es expedido hasta que se ejecuta este comando; además, mediante este esquema, el usuario obtiene un control de entrega completo, pero típicamente se utiliza más del lado del ordenador que del lado del terminal.
El último aspecto de los terminales virtuales es el de gestión de la atención. Todos los sistemas poseen alguna tecla, que el usuario del terminal puede apretar, para interrumpir el comando o programa en curso (tecla de suspensión, Del o borrar, etc.). De cualquier manera, el software del terminal virtual deberá tomar en cuenta esta acción, de alguna manera que permita que esta señal alcance cualquier dato que se encuentre ya en la línea.
©Arredondo Hernandez Edy Paul
El agente usuario
Usuarios que autorizan Quien expidió realmente el mensaje
Bajo cuya responsabilidad se expidió
Receptores principales
Receptores con copia
Receptores con copia ocultos A quien está dirigido el mensaje
Quien obtiene copias del mensaje
Quien obtiene secretamente copias del mensaje
Receptores de respuestas
Plazo de respuesta A quien debe enviarse la respuesta
Para cuando se desea la respuesta
Ident. del mensaje
En respuesta a
mensajes obsoletos
Mensajes relacionados Identificador del mensaje
Mensaje al que se responde
Mensajes invalidados por éste
Otros mensajes relacionados con éste
Asunto
Importancia
Sensibilidad De que trata el mensaje
Prioridad del mensaje
Público, confidencial en la empresa, etc.
Fecha de expiración Fecha cuando el mensaje deja de tener validez
El agente de transferencia de mensajes
· Facsímil analógico
· Facsímil digital
· Voz digitalizada
· Videotex
· Teles
· Externo (algún otro sistema)
2. Devolver el resultado de una operación invocada remotamente, a la persona que llama.
3. Devolver un mensaje de error a la persona que invoca.
4. Devolver la llamada a una operación remota, por ser inválida.
Dirección del originador
Dirección del receptor
Receptor alternativo permitido
Receptor alternativo
Dirección de correo del emisor
Dirección de correo del receptor
Está permitido reexpedir a otra gente
Receptor alternativo secundario Identificación del mensaje
PrioridadSolicitud de notificación del originadorSolicitud de notificación del MTA (Agente de Transferencia de Mensajes)
Entrega diferida
Fecha límite de entrega
Solicitud de devolución de contenido
Identificación del mensajeBaja (económica), normal, inmediata (cara)
Qué notificación desea el originador
Qué notificación desea el MTA
No entregar antes de este momento
No entregar después de este momento
Si no hay entrega deberá devolverse el contenido
Tipo de información
Conversión prohibida
Conversión imprecisa prohibida
Conversión explícita Texto, Facsímil, Voz digitalizada, etc
.Conversión no permitidaSólo se permite una conversión perfecta
Se sabe que se requiere conversión Identificación de cifrado
Comprobación de la integridad del contenido
Firma del originador
Etiqueta de seguridad del mensaje
Comprobación de entrega
Índice en la tabla de claves de cifrado
Código de redundancia del contenido
Firma digital
Clasificado, secreto, ultra secreto, etc.
Firma del receptor
Terminales virtuales
©Uriarte Ramírez José Rodolfo