Como ya se ha visto las posibilidades de un

buen servidor de correo deben permitir

establecer estructuras de funcionamiento
como las de la figura.
Para conseguirlo el administrador del sistema
deber:

Codificar los nodos.
Personificar el servidor que se arranca en cada nodo.
Informar de las vas de comunicacin disponibles entre los
nodos,personificando los routers.
Definir los usuarios y programas clientes.
Informar de los enlaces permitidos entre los nodos,lo que
equivale a informar la tabla de distribucin.
Informar los parmetros de auto correccin
Las posibilidades que el servidor de correo debe
dar al administrador del sistema Distribuido para
personificar y administrar el sistema son:


Codificar las vas de salida de que dispone cada elemento de la plataforma.
Identificar a cada usuario por un cdigo.
Permitir asignar permisos de acceso a cada usuario.
Escoger las vas de acceso, principal y alternativas, entre cada nodo / usuario que
estn autorizados a comunicarse. Cada camino puede ser directo o a travs de
otros nodos.
Poder definir por cada destino el nmero de reintentos a realizar y los criterios de
gestin automtica de errores.
Definir los parmetros de la cola de distribucin.
Cuando cambie una va entre dos nodos todos los usuarios afectados deben
quedar automticamente redefinidos.
Si se utiliza la opcin de control centralizado de errores, se habr de definir el
funcionamiento de la opcin para cada mensaje.
Limitar las posibilidades de funcionamiento para cada usuario en funcin de
sus necesidades y derechos en el sistema distribuido.

Como ya se ha visto el transporte tiene dos
partes, la anotacin y el contenido.
El contenido es un fichero del cual el Servidor de
Correo no necesita conocer nada ms que el
path de origen y el de destino.
En cuanto al formato de la anotacin, si se
recuerda que normalmente se trata de la
anotacin en una cola, no hace falta nada ms
que repasar en el captulo anterior como es el
formato de una anotacin en una cola. Adems
del origen y del destino, atributos como prioridad
y calificador son de gran inters en un servidor
de correo.

El cartero es un componente operacional que utiliza
sistemticamente el servidor de notas y avisos y que se encarga de
repartir un aviso a una lista de usuarios de forma automtica.
Necesita:

La gua de usuarios donde esta la direccin de acceso, normalmente la
de correo. Se recomienda aprovechar alguna entidad ya existente.
Las funciones que pueden usarlo. Por ejemplo, la llegada de albaranes
de un proveedor, la finalizacin de procesos Bach, etc. Suele incluirse
una especializacin de funcin que permite afinar el envo. La
especializacin puede, por ejemplo, dentro de la llegada de albaranes
ser el proveedor de origen, posibilidad que permite enviar el aviso a los
responsables de cada proveedor.
La relacin funciones-usuarios interesados.
El cartero averigua a partir de la relacin entre funcin y usuarios los
usuarios
destinatarios.
El cartero pasa los mensajes al servidor de notas y avisos.
El servidor de notas y avisos los hace llegar a los usuarios afectados.


La gestin de errores en un servidor de
correo es fundamental ya que su cualidad
bsica ha de ser la full tolerance.
La calidad de un ser servidor de correo en
este apartado puede medirse en dos
dimensiones:

Recuperacin de errores
Facilidad de localizacin y seguimiento
Ha de ser automtica y flexible. Cuando se inicia
una transferencia, ya sea en origen o destino, si
el otro lado no contesta se realizarn de forma
automtica un nmero de reintentos de
transmisin espaciados en un tiempo de espera
entre reintentos de transmisin. Si en uno de ellos
se recupera la conexin, sta se reinicia y
continua normalmente en el punto en que se
haba quedado sin repetir lo que ya se haba
transmitido. El usuario ni lo notar.
Como mucho, si el nmero de reintentos es alto,
puede llegar a notar que la transmisin ha
durado ms tiempo del normal.

La implementacin de los tiempos de espera entre reintentos de
conexin puede ser:
Lineal. La espera entre reintento y reintento es siempre la misma.
Progresiva. La distancia entre reintentos se alarga en funcin del
nmero de reintentos hasta un tope mximo a partir del cual es ya
lineal.
La progresin puede ser a su vez:
Geomtrica.
Escalada. Un ejemplo para un servidor de correo puede ser:
30 segundos para el primero. Se intenta solventar errores de transmisin
puntuales.
2 minutos para el segundo. Se intenta salvar una congestin.
4 reintentos de 30 minutos. Se intenta recuperar cadas por avera del
transportista.
Espera de 8 horas y reinicio del ciclo. Se intenta recuperar averas de la
plataforma.

Si los nodos origen y destino tiene una conexin por va alternativa, todo el
proceso se reintentar por ella.
Si la opcin de loging est activada todas las incidencias ocurridas sern
registradas.
Obviamente todos estos parmetros pueden ser personalizados esttica y
dinmicamente para cada nodo.
El diseo de la recuperacin de errores es genrico a todos los procesos
distribuidos variando en cada caso la poltica del tiempo de progresin.
Existe la posibilidad de establecer tipologas de estrategias que se pueden
cuantificar diferentemente en funcin de las necesidades concretas de cada
nodo
El administrador del sistema tendr a su
disposicin varios recursos:
Loging de errores.
Control centralizado de errores.
Jerarqua de errores.
Mdulo de seguimiento y anlisis



Loging de errores.

De forma parametrizada, el servidor de correo registrar un loging
de incidencias y errores que permitir obtener informacin por
nodo,tipologa, frecuencia, etc.
El paquete estadstico consulta y anlisis de errores, basado en el
loging, puede ser un paquete proporcionado por el mismo
diseador del servidor de correo (integrado o no el modulo de
seguimiento y anlisis del que se habla ms adelante) o realizado
a medida a partir de herramientas de usuario tipo Access.

Control centralizado de errores.
El servidor puede dar la opcin de organizar un control
centralizado de errores de forma que toda la informacin de
errores e incidencias se enven a un punto de sistema distribuido
donde hay un administrador.
Este control se organizar basado en la gestin jerrquica de
errores que se presenta a continuacin.
Esta opcin slo tiene inters en instalaciones muy grandes o en
aquellas en que en los puntos de origen y destino no tienen
administracin de sistema y la existencia de errores puede pasar
desapercibida.



Jerarqua de errores
La clasificacin y calificacin de los errores es de inters tanto para el loging como
para el control centralizado.
Los errores se clasificarn en dos grupos: graves y incidencias. Dentro de cada grupo a
cada error se le asignar un cdigo.

Si se ha de grabar en el loging.
Si de ha de enviar al control centralizado de error y como ha deinformarse all al
administrador:
Nota: se depositar hasta que el administrador lo consulte voluntariamente.
Aviso: se depositar hasta que el administrador lo consulte antes de un tiempo
parametrizable. Si pasado ese tiempo nolo ha hecho se interrumpir al administrador.
Fuego: se interrumpir al administrador en su trabajo para notificarle el error.
Obviamente est interrupcin slo se aplicar a errores graves.

Mdulo de seguimiento y anlisis
Todas las posibilidades de consulta, seguimiento y gestin centralizada pueden estar
integradas en un mdulo de seguimiento y anlisis.
Las posibilidades de este mdulo son, como mnimo:
Seguimiento en tiempo real de errores con grabacin de loging y envo de notificacin
al control centralizado.
Estadsticas por pantalla y listado.
Herramientas de anlisis.
Utilizacin por usuarios y distribucin y control de costes.
Posibilidad de incorporar mdulos personificados por usuario segn sus necesidades y
organizacin.
Gestin de la seguridad.

Push
El cliente anota en origen y el servidor de correo de
origen inicia el envo segn una poltica.
El push ha de ser multivia para poder lanzar ms de un
envo simultneamente.Puede ser:
Inmediata. El servidor de correo
Diferida. Esta modalidad puede ser necesaria, aun con
una plataforma continuamente abierta, si la entrega
no se puede hacer efectiva por razones funcionales de
la aplicacin. La entrega puede ser:
Planificada. La entrega se realiza en bloque con todo lo
pendiente.
Por anotacin. Se asocia una hora de entrega y
cuando es el momento se inicia el transporte desde
origen.
Recogida.
El destino inicia la comunicacin, mira si hay algo para l y lo
recoge.Aprovecha la opcin de captura del servidor de correo. Puede ser:
Planificada.
Por necesidades de aplicacin, muchas veces iniciada por un agente en
destino.
Tiene la ventaja de que la banda de comunicaciones que se necesita es
menor ya que la recogida es escalada

Notificacin.
Es un sistema intermedio en el cual el origen avisa al destino que tiene una
entrega para l. El destino la recoger cuando le convenga.
En la notificacin se incluye informacin del contenido de la entrega y
posibles destinatarios en el nodo destino. El aviso puede llegar:
El servidor de notas y avisos.
El cartero.
Un sistema de viga.
Un evento convencional si hay una plataforma de eventos distribuida

Oportunista.
Cuando el nodo remoto se conecta para pedir algn servicio, aprovecha
para preguntar si hay algo para l.Suele incluirse, como parte de la
respuesta del servicio pedido, una notificacin, dedicada o general, de
que hay alguna cosa para l




En este punto de la exposicin ya le debe ser muy
evidente el uso que puede hacer de un buen servidor de
correo y de su especializacin como servidor de notas y
avisos.
Sin embargo, si usted no puede aprovechar un paquete
ya construido, conseguir todas estas prestaciones supone
un esfuerzo importante de programacin. Pero, si su
diseo necesita construir uno, no caiga en el error de
programarlo sin las prestaciones mnimas para ahorrar
costes. No conseguir la tolerancia total ante fallos y eso
arruinar su proyecto. Adems la experiencia demuestra
que un buen servidor de correo crea adicin: cuanto ms
se usa ms necesidades se encuentran, y mejor quedan
sus aplicaciones distribuidas.
Finalmente otra obviedad: fabricar un servidor de correo
slo se justifica en topologas distribuidas heterogneas,
globales o muy grandes