universidad de magallanes. facultad de ingenier´ıa ... · administrador de discos: el nodo...

Universidad de Magallanes. Facultad de Ingenierıa, Departamento de Ingenierıa en Computacion e Informatica.

Propuesta de un sistema distribuido de correos

electronicos.Moises Ivan Llancapani Stormensan.

A continuacion de dara a conocer el modelo del sistemadistribuido, sus componentes y la explicacion de como funcionadetalladamente cada uno de ellos para que ası uniendo todos,pueda funcionar completamente el sistema.

Componentes del sistema.

Primero se deben tener algunos requerimientos para queel sistema pueda funcionar de manera correcta. Por lo cual acontinuacion se nombraran sus componentes y una descripcionde cada uno de ellos.

Existira un nodo receptor, este se encargara de recibir elcorreo electronico y distribuirlo de forma equilibrada a los otrosnodos para que se lleve a cabo la distribucion equilibrada:

SMTP[3]: El nodo receptor podra transferir un correoelectronico a otro servidor, ası como tambien recibir correoselectronicos desde otro servidor.

POP[2]: El nodo receptor trabajara con el protocolo POPque permite la captura del correo electronico para ası procedera realizar la lectura de este y mas tarde la distribucion.

IMAP[1]: Permite acceder a los mensajes desde cualquiercomputador que tenga acceso a internet, el nodo receptorpodra realizar esta operacion.

Agente de Entrega de Correos: Permite almacenar los co-rreos electronicos en el buzon de correo correspondiente, estoquiere decir, que todos los nodos tendran un buzon de correos.

Agente de Usuario de Correo: Permite la lectura y envıode un correo electronico a traves de una interfaz.

Buzon de Correo: Cada nodo debera almacenar los correoselectronicos de los usuarios, aunque la bandeja sera distinta pa-ra todos los nodos en cuanto a contenido y los usuarios de estoscorreos podrıan ser cualquiera ya que el sistema esta totalmentedistribuido.

Administrador de Usuarios: Un nodo debera administrarunicamente a un usuario, los usuarios no se repetiran en los no-dos, o sea, cada usuario tendra su propio nodo administrador.

Administrador de Discos: El nodo receptor debera poseerinformacion de los demas nodos en cuanto a espacio ocupadoen su disco duro, para ası al momento de tener que distribuirun correo, se pueda realizar de forma distribuida.

Identificador Usuario/Nodo: Los nodos poseen un moduloen el cual les permite identificar para cada usuario, su nodoadministrador.

Envıo de Correos Electronicos

Para enviar un correo electronico se necesita de unadireccion de correo al cual se enviara, por ejemplo, [email protected]. Al momento de enviar un correo electroni-co, el nodo receptor, debe verificar a que usuario se envıa talmensaje para ası identificar el nodo administrador del usuario.

Nodo Receptor: Es aquel que recibe un correo electronico,y es el que realiza todo el trabajo de verificar donde se encuen-tra el nodo administrador, y almacenar el correo electronico enel nodo debido.

Nodo Administrador de Usuarios: Cada nodo administra-dor contendra una lista de los usuarios a los cuales va a ad-ministrar. En la respectiva lista, el nodo almacena informacionde cada usuarios, los correos que posee y el lugar donde estanalmacenados estos correos electronicos, es decir, en que nodose encuentra ubicado. La lista tiene forma de la Figura 1.

Figura 1: Indice invertido. Los correos electronicos que posee el

usuario y los nodos donde estan almacenados dichos correos.

Almacenamiento de Correos Electronicos en los Nodos.

Para almacenar los correos electronicos, el nodo receptordel mensaje debera consultar por el espacio ocupado en cadamemoria de los discos duros de cada nodo, para ası poder de-cidir donde se almacenara el correo recibido, como el sistema

1

debe ser distribuido y equilibrado, el correo electronico se de-be ir almacenando en el nodo que tenga mas espacio libre ensu disco duro, si todos tienen la misma cantidad ocupada, elnodo se escoge de forma aleatoria, de esta forma se lleva unadistribucion de manera balanceada.

A medida que los nodos vayan recibiendo correos, se envıala informacion necesaria a todos los nodos de todos los nodos,tales como, capacidad total, espacio ocupado, y espacio libre sies necesario, ası el nodo receptor puede realizar sin problemasla eleccion del nodo donde se va a almacenar el mensaje.

Despues de almacenar el mensaje, se envıa la informacional nodo administrador de usuario sobre el correo electronico,y el nodo donde se almaceno este, para que ası el nodo admi-nistrador pueda ingresar esta informacion a la lista de ındicesinvertidos de usuarios.

Basicamente la estructura de envıo de correos electronicosserıa como se muestra a continuacion:

Se envıa un correo electronico a un usuario, y este correoes recibido por el nodo receptor.

El nodo receptor decide cual es el mejor nodo para alma-cenar el mensaje (el nodo con menos espacio ocupado en discoduro), de acuerdo a sus registros almacenados de los diferentesnodos y sus espacios ocupados en disco.

Luego de almacenar el correo electronico, el Nodo receptorverifica cual es el nodo administrador del usuario al que se leenvio el correo electronico, esto se hace por medio de la funcionhashing explicada anteriormente, ası le envıa los datos como elusuario y el Nodo donde se almaceno.

Lectura de un Correo Electronico.

Para leer un correo electronico el usuario necesita ver subandeja de entrada. En el caso del sistema distribuido, la ban-deja de entrada se puede encontrar ubicada en mas de un nodoya que el sistema esta totalmente disperso por el metodo debalanceo.

El primer paso es ubicar donde estan almacenados todoslos correos electronicos del usuario. Para esto el protocolo quese utiliza es el POP (que sera modificado) que permite la re-cuperacion de los correos electronicos, pero en nuestro caso,este protocolo debera recuperar los correos de distintos nodoso servidores para que ası el usuario posteriormente pueda in-teractuar con sus mensajes.

Como primer paso se debera verificar cual es el nodo admi-nistrador del usuario, esto se hace aplicando la funcion hashingmencionada anteriormente. Luego que ya se tiene el nodo ad-ministrador, se consulta por los correos electronicos que posee,y en que servidor esta almacenado.

Al momento de saber donde estan almacenados los correosdel usuario, procede a actuar el protocolo POP, que se encarga

de captura el o los correos electronicos que se necesitan leer,estos correos se capturan desde los diferentes nodos. Luego elagente de usuario de correo es el que se encargara de que elusuario pueda leer el correo mediante alguna interfaz.

En la Figura 2 se muestra un diagrama de los componentesdel sistema y las comunicaciones entre ellos.

Figura 2: Diagrama del servidor y sus componentes.

Prototipo del Sistema

A continuacion se dara a conocer los dos tipos de imple-mentacion de prototipos realizados, con nodos virtuales y nodosreales.

Ambos prototipos realizan las mismas funciones, la uni-ca diferencia es que el prototipo con nodos virtuales trabajacon directorios en un solo equipo, por el contrario, el prototipocon nodos reales trabaja con mas de un equipo, es decir, condirectorios compartidos en la red.

Estos prototipos estan programados en el lenguaje c++,y compilados con g++ con la version 4.3.2.

Para comenzar se debe tener en cuenta diferentes cosas queson cantidad de nodos, capacidad de los nodos y el listado deusuarios, para esto se modifican dos archivos de configuracion

2

para los correspondientes datos.

Teniendo estos dos archivos listos se procede a correr laaplicacion, donde se crearan los nodos virtuales, que son direc-torios en el mismo computador. A cada nodo se le asignaranusuarios, que son los ya ingresados en el archivo. Un usuariose almacenara en su respectivo nodo administrador, explicadoya en el modelo del sistema, es decir, en cada carpeta crea-da para cada nodo, se almacenara un archivo en el cual estancontenidos los respectivos usuarios.

Tambien se crea una lista local en el nodo receptor, paraque ası este nodo pueda realizar mas rapida la busqueda deun usuario al momento de que se quiera almacenar un correoelectronico o leerlo, esta lista tambien almacena la capacidadde los demas equipos computacionales.

Al momento de decidir si realizar el almacenamiento ybusqueda de usuarios en forma secuencial o mediante hashing,se opto por la segunda opcion, porque ya que al momento dealmacenar, el tiempo que se obtiene con ambos tipos es practi-camente el mismo, como se muestra en la Figura 3.

0

5

10

15

20

25

0 20 40 60 80 100

Tiempo de almacenamiento en microsegundos

Cantidad de usuarios

Tiempo de almacenamiento

Almacenamiento aplicando HashingAlmacenamineto sin aplicar Hashing

Figura 3: Tiempos de almacenamiento.

Pero al momento de realizar la busqueda se obtienen dis-tintos resultados de acuerdo al metodo de busqueda que serealice.

En la Figura 4 se realiza la busqueda de forma secuencialy se puede visualizar que a medida que se avanza con dichabusqueda de usuarios, el tiempo que transcurre es mayor, has-ta que la cantidad de usuarios buscados sea igual a la cantidadde nodos, luego vuelve a disminuir el tiempo de busqueda y serepite el mismo proceso.

0

10

20

30

40

50

0 20 40 60 80 100

Tiempo de busqueda en microsegundos


Tiempo de busqueda

Busqueda sin aplicar Hashing

Figura 4: Tiempo de busqueda sin hashing.

En la Figura 5 se realiza la busqueda utilizando el metodode hashing, y como se puede observar, el tiempo que toma rea-lizar cada busqueda de cada usuario es casi similar y ademasmuy pequeno.

0

10

20

30

40

50

0 20 40 60 80 100



Tiempo de busqueda

Busqueda aplicando Hashing

Figura 5: Tiempo de busqueda aplicando hashing.

Luego despues de haber observado los tiempos que tardanambos tipos de busqueda, se realiza una comparacion de ellos,como se muestra en la Figura 6, y se puede visualizar que al uti-lizar la busqueda son el metodo de hashing, disminuye muchocon respecto a la busqueda secuencial, por lo cual se utilizo elalgoritmo que minimiza los tiempos de busqueda.

3

0

10

20

30

40

50

0 20 40 60 80 100



Tiempo de busqueda

Busqueda aplicando HashingBusqueda sin aplicar Hashing

Figura 6: Comparacion de tiempos de busqueda.

Al utilizar el algoritmo de hashing, este no realiza labusqueda en los nodos innecesarios, porque con este metodo,se conoce ya el nodo donde se deberıa encontrar el usuarios abuscar.

Tambien ası para las busquedas infructuosas, como semuestra en la Figura .

0

10

20

30

40

50

60

0 20 40 60 80 100



Tiempo de busqueda infructuosa


Figura 7: Comparacion de tiempos de busqueda infructuosa.

El tiempo de busqueda infructuosa utilizando el metodode hashing es bastante mas bajo que el de forma secuencial, yaque este ultimo recorre la lista completamente para encontrarun usuario, en cambio, al utilizar hashing, solo se realiza labusqueda en el nodo donde podrıa estar un respectivo usuario,y la lista se reduce mucho.

Luego, al tener el servidor funcionando, este solo espera aque se reciba un correo electronico en la cola de correos.

Cuando se recibe un correo electronico, el nodo receptorlo almacena en la cola de correos, desde ahı se captura y seprocesa obteniendo primeramente el usuario al cual se le esenviado.

Luego de obtener el usuario al cual se le envıa el correoelectronico, el programa verifica si existe en la lista local.

Cuando el usuario se encuentra en la lista, se debe recono-cer cual es el mejor nodo para almacenar el correo electronico,y para que el sistema este balanceado, el mejor nodo sera elque tenga menos espacio ocupado en el disco.

Posteriormente el correo electronico es almacenado en unarchivo de texto que es llamado la bandeja de entrada del usua-rio, para esto se crea una carpeta con el nombre del usuario enel servidor apropiado para almacenar el correo electronico. Es-to se realiza por cada usuario, pero solo la carpeta es creadaen el nodo si existe algun correo electronico del usuario, de locontrario, el usuario no debe tener una carpeta creada.

Luego de almacenar el correo electronico, se vuelve a calcu-lar el espacio ocupado que tiene el nodo donde fue almacenadoel correo electronico, dicha cantidad ocupada se resta a la ca-pacidad total del nodo actualizando ası la lista local y el detallede las capacidades.

Luego de actualizada la lista local con las capacidades, seprocede a trabajar con la misma lista local, pero esta vez lalista de usuarios, como se tiene en cuenta, la lista consta delos nodos creados que son los servidores, y estos nodos con-tienen una lista de usuarios los cuales administra. Ahora estosusuarios van a contener apuntadores que indiquen donde tie-nen almacenado sus correos electronicos, puede apuntar haciaun nodo, o a todos, dependiendo de donde tenga el usuariodistribuidos sus correos.

Al terminar de actualizar la lista local con la informacionde los usuarios y donde estan contenidos sus correos electroni-cos, esta informacion se almacena en cada carpeta correspon-diente a cada nodo. Como se menciono anteriormente, existe unarchivo en cada nodo donde estan contenidos los usuarios a loscuales administra, entonces, en ese mismo archivo se agreganlos nodos los cuales estan almacenados los correos electronicos.

Envıo del correo electronico.

Para realizar el envıo de correos en el prototipo, solo serequiere de comenzar la aplicacion y ejecutar los comandosSMTP, ası el nodo receptor los captura y los procesa.

Lectura del correo electronico.

Para proceder a realizar la lectura de los correos electroni-cos, basicamente se necesita solo el usuario al cual se le quiereleer dichos correos, y nos mostrara cuantos correos se tienen enla bandeja de entrada, para ası, escoger cual de ellos se quiereleer.

Entonces, se toma el nombre de usuario, se le aplica lafuncion hash para obtener su nodo administrador, este nodoindica en que servidores estan almacenados sus correos, y semuestra una lista de todos ellos enumerados, para ası procedera leerlos.

4

Para realizar la aplicacion con los nodos reales se necesitaque el nodo receptor de los correos electronicos logre accedera los directorios de los otros servidores, ası poder almacenarlos correos electronicos de los usuarios en cada uno de ellos ymantener el balanceo del sistema.

Para llevar a cabo esto, se utilizo el protocolo SaMBa[4].

Se instalo samba en cada uno de los servidores, luego secrearon los directorios en el nodo receptor de correos electroni-cos para poder montar los demas directorios compartidos.

En el directorio /mnt se creo la carpeta Servidores, y den-tro de esa carpeta se crearon los directorios dependiendo decuantos nodos existan.

Luego se debe configurar cada servidor para que puedaser visualizado como compartido en la red. Para hacer estose debe establecer un directorio donde se almacenaran los co-rreos electronicos. Este directorio sera visto a traves de la redcomo compartido y el nodo receptor de correos electronicos de-bera montarlos en las carpetas creadas para ası poder trabajarcon ellos.

Ası finaliza al prototipo del sistema.

Referencias

[1] RFC. Internet message access protocol. http://tools.

ietf.org/html/rfc3501.

[2] RFC. Post oficce protocol. http://www.ietf.org/rfc/

rfc1939.txt.

[3] RFC. Simple mail transfer protocol. http://tools.ietf.

org/html/rfc5321.

[4] WWW. Samba. http://es.wikipedia.org/wiki/Samba_

(programa).

Biografıa

Moises Ivan Llancapani Stormensan nacio en Punta Are-nas, Chile, el 30 de diciembre de 1986. En la ensenanza basicaestudio en la Escuela D-17 Bernardo O’Higgins Riquielme y enla ensenanza media estudio en el Instituto Superior de Comer-cio Jose Menendez obteniendo el tıtulo de Tecnico en mandomedio de contabilidad. Para obtener el tıtulo de Ingenierıa enComputacion e Informatica se presenta este tema presentadoactualmente en la fecha 22 de marzo del 2010.

5

UNIVERSIDAD DE MAGALLANES

FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA EN COMPUTACION

Propuesta de un sistema distribuido

de correos electronicos.

Moises Ivan Llancapani Stormensan.

2010

La presente Memoria de Titulacion ha sido aprobada con la siguiente calificacion:

Moises Ivan Llancapani Stormensan

Memoria :

Examen de Tıtulo :

Nota Final :

Sr. Pedro Alberti

Director Departamento

de Ingenierıa en Computacion

22 de marzo de 2010

UNIVERSIDAD DE MAGALLANES

FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA EN COMPUTACION

Propuesta de un sistema distribuido


Trabajo de titulacion presentado en

conformidad a los requisitos para obte-

ner el tıtulo Ingenierıa en Computacion

e Informatica.

Profesor Guıa: Jose Canuman Chacon.

Moises Ivan Llancapani Stormensan.

2010

Agradecimientos

A Dios.

Por estar conmigo en cada paso que doy, por fortalecer mi corazon e iluminar mi mente y

por haber puesto en mi camino a aquellas personas que han sido mi soporte y companıa

durante todo el perıodo de estudio.

A mis Padres.

Jose y Rebeca, los mejores profesores de mi vida. Porque gracias a su carino, guıa,

apoyo y consejos he llegado a realizar la mas grande de mis metas, la cual constituye

la herencia mas valiosa que pueda recibir de ellos. Vivire eternamente agradecido de

ustedes. Los amo.

A mi hermana.

Daniela, por darme la estabilidad emocional para poder llegar a este logro, que defini-

tivamente, no lo hubiese logrado sin tı y sin tu carino eterno. Muchas gracias por todo.

Te amo.

A mi hijo.

Ian Ignacio, como un testimonio de gratitud ilimitada, porque su presencia ha sido y

sera siempre el motivo mas grande que ha impulsado para lograr esta meta. Te amo.

A Daniza.

Fuiste mi apoyo durante este agradable pero complicado proceso, gracias por estar a

mi lado y seguir siendo parte de mi vida. Te amo.

A mis abuelos.

Que siempre estuvieron a mi lado, y a tı abuelo Florencio que siempre me apoyaste en

vida y me diste tu sabidurıa, y se que desde lo mas profundo de tus suenos, estaras

junto a mı eternamente. Los tendre siempre en mi corazon.

1

A mis tıos.

Que han vivido conmigo la realizacion de esta etapa, en especial a mi tıo Carlos Saldivia,

que desde pequeno me apoyo en todo ambito y por ensenarme que no hay lımites, que

lo que me proponga lo puedo lograr y que todo depende de mı. Muchas gracias.

A mis primos.

Que han estado en todo momento junto a mı, les agradezco por haberme brindado todo

el apoyo. Gracias.

A mis amigos.

A todos ellos, pasados y presentes, pasados por ayudarme a crecer y madurar como

persona, y presentes por estar siempre conmigo apoyandome en todas las circunstancias

posibles. Los valoro.

A mi profesor guıa.

Don Jose Canuman Chacon, por su colaboracion, apoyo, paciencia y sobre todo sus co-

nocimentos brindados y ayuda cuando mas lo necesitaba, ası como tambien su amistad.

Eternamente agradecido.

A mis profesores.

Por darme sus conocimentos para poder llegar a finalizar esta etapa de mi vida, muchas

gracias a todos ustedes.

A todos aquellos que han quedado en los lugares mas escondidos de mi memoria, pero

que fueron participes de este logro, gracias.

2

Resumen

En la actualidad las bases de datos son tan inmensas que se requiere aprovechar mejor

de la capacidad de almacenamiento, y para cumplir esto, se necesita que la base de datos sea

distribuida en mas de un computador.

De esta forma nace el proyecto de proponer un sistema distribuido para los correos

electronicos ya que este medio de comunicacion es muy utilizado hoy en dıa.

Un sistema distribuido de correos electronicos es un conjunto de datos, en este caso

serıan los mismos correos electronicos, estos datos estan almacenados sobre una red, o sea, la

informacion esta almacenada en diferentes sitios de esta, y cada informacion de los diferentes

sitios constituira una sola base de datos.

3

Indice general

I. Introduccion 1

1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

II. Marco Teorico 3

2.1. Correo Electronico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2. El Telegrafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3. Servidor de Correos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.4. El Correo Electronico . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.5. Protocolos de Mensajerıa . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1. Caracterısticas de una Base de Datos . . . . . . . . . . . . . . . . . . 18

4

2.3. Base de Datos Distribuidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

III. Modelo del Sistema 20

3.1. Componentes del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2. POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.4. Agente de Entrega de Correos . . . . . . . . . . . . . . . . . . . . . . 22

3.1.5. Agente de Usuario de Correo . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.6. Buzon de Correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.7. Administrador de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.8. Administrador de Discos . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.9. Identificador Usuario/Nodo . . . . . . . . . . . . . . . . . . . . . . . 23

3.2. Envıo de Correos Electronicos . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1. Nodo Receptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2. Nodo Administrador de Usuarios . . . . . . . . . . . . . . . . . . . . 23

3.2.3. Almacenamiento de Correos Electronicos en los Nodos . . . . . . . . 26

3.3. Lectura de un Correo Electronico . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4. Diagramas del Modelo del Sistema . . . . . . . . . . . . . . . . . . . . . . . 33

IV. Prototipo del Sistema 36

5

4.1. Prototipo del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1. Prototipo con Nodos Virtuales . . . . . . . . . . . . . . . . . . . . . . 37

4.1.2. Prototipo con Nodos Reales . . . . . . . . . . . . . . . . . . . . . . . 56

4.2. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

V. Servicios Propuestos. 59

5.1. Servidor de Correos Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.1. Ventajas de Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2. Sistema HA Bajo Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.1. Heartbeat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.2. Balanceador de Carga con HAProxy/Keepalived . . . . . . . . . . . . 64

VI. Conclusiones 66

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.1.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.1.2. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

VII.Bibliografıa 70

Indice de figuras

2.1. Varios clientes conectados a un servidor. . . . . . . . . . . . . . . . . . . . . 5

2.2. Accediendo al servidor de forma remota. . . . . . . . . . . . . . . . . . . . . 6

2.3. Dos LAN accediendo a los distintos servidores. . . . . . . . . . . . . . . . . . 7

2.4. LAN conectada a INTERNET. . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5. LAN conectada a INTERNET mediante un contrato ISP. . . . . . . . . . . . 10

2.6. LAN utilizando los protocolos SMTP y POP. . . . . . . . . . . . . . . . . . . 11

3.1. Indice invertido. Los correos electronicos que posee el usuario y los nodos donde

estan almacenados dichos correos. . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2. Ejemplo de aplicacion de la funcion hashing a ‘usuario1’. . . . . . . . . . . . 25

3.3. El nodo receptor recibe el correo electronico. . . . . . . . . . . . . . . . . . . 27

3.4. Detalle de las capacidades de los discos duros de los diferentes nodos. . . . . 28

3.5. Detalle de las capacidades de los discos duros despues de haber almacenado el

correo electonico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6. Insertando un nuevo correo a la lista de ındices invertidos. . . . . . . . . . . 30

7

3.7. Pasos para la lectura de un correo electronico. . . . . . . . . . . . . . . . . . 32

3.8. Diagrama del servidor y sus componentes. . . . . . . . . . . . . . . . . . . . 33

3.9. Diagrama del envıo de un correos electronico. . . . . . . . . . . . . . . . . . 34

3.10. Diagrama de la lectura de un correo electronico. . . . . . . . . . . . . . . . . 35

4.1. Tiempos de almacenamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2. Tiempo de busqueda sin hashing. . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3. Tiempo de busqueda aplicando hashing. . . . . . . . . . . . . . . . . . . . . 44

4.4. Comparacion de tiempos de busqueda. . . . . . . . . . . . . . . . . . . . . . 45

4.5. Comparacion de tiempos de busqueda infructuosa. . . . . . . . . . . . . . . . 46

4.6. Envıo de correo electronico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7. Estructura del nodo de un usuario y su arreglo de punteros inicializado. . . . 50

4.8. Lista de nodos servidores y usuarios. . . . . . . . . . . . . . . . . . . . . . . 51

4.9. Estructura del nodo de un usuario y su arreglo de punteros modificado. . . . 52

4.10. Tiempo de busqueda con 5 y 10 nodos. . . . . . . . . . . . . . . . . . . . . . 58

5.1. Configuracion de servidores para HAproxy/Keepalived. . . . . . . . . . . . . 65

Indice de cuadros

2.1. Comandos del protocolo SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2. Comandos del protocolo POP3. . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1. Lista de usuarios almacenados con hash (1). . . . . . . . . . . . . . . . . . . 39

4.2. Lista de usuarios almacenados con hash (2). . . . . . . . . . . . . . . . . . . 39

Capıtulo I

Introduccion

CAPITULO I. INTRODUCCION 2

1.1. Objetivos

Con la finalidad de realizar la distribucion de correos y manejar el contenido equilibrada-

mente, surge el nacimiento de los siguientes objetivos:

1.1.1. Objetivo General

Proponer un sistema distribuido de correo electronico de manera balanceada.

1.1.2. Objetivos Especıficos

Los objetivos especıficos son:

Investigar los servidores de correos existentes y que sean apropiados para realizar la

distribucion de correos.

Investigar sobre algun servicio que permita sincronizar los computadores.

Buscar un servicio que permita trabajar con servidores de modo activo/pasivo, de modo

que si uno falla, el otro se active automaticamente.

Realizar un prototipo que simule la distribucion de los correos electronicos.

Capıtulo II

Marco Teorico

CAPITULO II. MARCO TEORICO 4

En el siguiente capıtulo se dara a conocer todo lo relacionado con un sistema distribuido

y la comunicacion vıa correo electronico, tanto de las necesidades por las cuales surgieron

estos servicios ası como una explicacion detallada sobre ellos.

2.1. Correo Electronico

2.1.1. Historia

El humano se ha caracterizado por ser netamente social, y se diferencia de las demas

especies por su capacidad de razonamiento, la cual segun algunas teorıas psicologicas se

manifiesta por medio del lenguaje, es decir, la habilidad de comunicarse, que permite al

hombre exteriorizar sus pensamientos. La forma mas primitiva de comunicacion implicaba

la presencia fısica de ambas partes, tanto emisor como receptor debıan estar juntos para

establecer la comunicacion.

Con la llegada de la escritura esto cambio radicalmente, ya no era necesario la presencia de

ambas partes para poder establecer una comunicacion. En cambio se necesito del transporte

fısico del mensaje, generalmente en papel, y ası nacio el primer concepto de portadora de un

mensaje. Los antiguos incas implementaron un sistema de transmision de mensajes utilizando

personas que recorrıan la extension de su reino, llevando consigo y pasando de boca en boca

el contenido del mensaje hasta que este alcanzara su destinatario.

Este primer intento de un sistema de correo se acerca bastante al que funciona actualmente

a nivel mundial. Un poco mas refinado, con jerarquıas de distribucion, legislacion que lo regula

y protege, pero el concepto es el mismo, el transporte fısico de un mensaje. El problema de

este sistema es que utiliza medios de transporte y por lo tanto son caros y lentos.

Cuenta la leyenda que mientras Samuel Morse viajaba por Europa, su madre en EE.UU.

cayo gravemente enferma, inmediatamente su familia intento contactarlo por medio de una

carta, pero cuando esta llego a el su madre ya habıa fallecido. Esta situacion llevo a Morse

a realizar una profunda investigacion sobre la transmision de la corriente electrica a traves


de un cable, la cual finalizo con la invencion del telegrafo, y ese fue el primer medio de

transmision electrico que se tiene registro. Pronto las lıneas telegraficas se extendieron por

todo el mundo y cuando estas lıneas no podıan establecerse se recurrio a la radio transmision,

ahora se contaba con un medio de transporte rapido y relativamente barato[13].

2.1.2. El Telegrafo

El telegrafo fue casi totalmente reemplazado 40 anos despues de su nacimiento por el

revolucionario invento de Graham Bell, el telefono, que 120 anos despues sigue en vigen-

cia. Este sistema tiene una escala global y conecta una inmensa jerarquıa de conmutadores,

multiplexores y conversores de senales que permiten una comunicacion a cualquier lugar del

mundo. Este sistema se adecua perfectamente para la transmision de voz de un lugar a otro,

pero para la transmision de datos resultaba bastante deficiente por lo que se construyo pa-

ralelamente a la red telefonica la red de telex, tambien proporcionaba una relativa seguridad

ya que estas maquinas tenıan una especie de protocolo para establecer su comunicacion. A

medida que pasaron los anos la informacion fue ganando importancia en la vida empresarial y

ya en los 60 las grandes companıas comenzaron a instalar grandes computadores y a conectar

terminales a ellos, teniendo ası acceso a su informacion y a sus recursos[13].

2.1.3. Servidor de Correos

Figura 2.1: Varios clientes conectados a un servidor.


Esta gran computadora o Mainframe hacıa las veces de servidor a las terminales que

servıa, de ahı que tambien se la llamara Server (Servidor). Dependiendo de los servicios que

proporcionara se denominarıa File-Server (servidor de archivos), Print-Server (servidor de

impresion). Luego de que los usuarios se familiarizaran con esta nueva metodologıa de trabajo,

se hizo evidente la posibilidad de hacer que los usuarios mismos pudieran dar informacion a

otros, sin la necesidad que tuvieran que estar fısicamente juntos, ası surgio la implementacion

de un Mail-Server (servidor de correo) como el que se muestra en la Figura 2.1.

2.1.4. El Correo Electronico

El correo electronico comenzo como la posibilidad que permitıa a distintas personas que

trabajan para una empresa que tenıa una LAN, trabajar juntos. Luego se vislumbro la po-

sibilidad de hacer que un usuario pudiera acceder a este mismo servicio en forma remota es

decir sin estar conectado a la red, en realidad conectado por medio de una lınea telefonica y

un MODEM, como se muestra en la Figura 2.2.

Figura 2.2: Accediendo al servidor de forma remota.


Figura 2.3: Dos LAN accediendo a los distintos servidores.

El siguiente paso en la expansion era conectar varias LAN, para que intercambien infor-

macion dirigida a los diferentes usuarios, como se puede ver en la Figura 2.3.

Esta implementacion incluıa una dificultad adicional, porque cada servidor de correos

deberıa reconocer sus usuarios locales, es decir, los que estan conectados a su misma red, y

a los usuarios remotos, que estan ubicados en otra red, ası introducirıan las direcciones de

correo y los dominios.

El envıo de un mensaje de correo, consistıa originalmente en que un usuario escribıa el

mensaje en un programa de aplicacion llamado cliente de correo, en contraposicion con el

servidor de correo, que consistıa de un editor de texto, posiblemente un corrector ortografico,

una base de datos de la forma de una libreta de direcciones, un administrador de archivos (los

mensajes recibidos o no enviados) y un modulo de comunicaciones para poder transferirlos.


El mensaje quedaba almacenado en el servidor de correos hasta que el usuario destinatario

usando su cliente de correo se conectara con el y solicitara los mensaje que tuviera reservados,

el proceso inverso de envıo de mensajes era muy parecido cuando el usuario terminara de

escribir su mensaje, especificando la direccion de el destinatario, se conectaba con el servidor

a fin de depositar el archivo hasta que el destinatario lo solicitara. Cuando el servidor esta co-

nectado a solo una red la unica limitacion de la direccion de destino, ademas de no permitir

espacios en blanco en la direccion, era que cada direccion debıa identificar de forma unıvoca

a cada usuario, con una LAN esta restriccion es facil de implementar pero con mas de una ya

pasa a ser un problema mayor; ası se introducen los dominios de los usuarios que representan

a que servidor pertenecen y que tienen la forma de una direccion valida, es decir sin espacios

en blanco ni caracteres prohibidos, para diferenciar el nombre del usuario de su dominio se

adopto el caracter ‘@’ que significa ‘en’ (at) entonces la direccıon usuario1@Servidor A se

puede leer como “usuario1 en Servidor A”.

Un problema surgio cuando se intentaron, conectar servidores de correo que utilizaban

productos comerciales distintos, que aunque conceptualmente hacıa lo mismo eran totalmente

incompatibles. El hecho era que hasta el momento no existıa un estandar que reglamentara

como debıan implementar los productos este servicio. La necesidad de un estandar se hizo

mas patente cuando redes totalmente distintas comenzaron a conectarse mediante INTER-

NET. Una companıa, posiblemente multinacional, que tuviera asiento en distintos paıses del

mundo y quisiera intercambiar correos, tenıa que contratar a un ISP (INTERNET SERVICE

PROVIDER) y ası tener acceso ilimitado a INTERNET. Este arreglo podrıa tener la forma

de la Figura 2.4.


Figura 2.4: LAN conectada a INTERNET.

Como solucion a este caos de variedades de mensajes de correos totalmente incompatible,

dos estandares, el primer estandar se denomino SMTP (simple mail transfer protocol), el

protocolo simple de transferencia de mail, y la intencion era que conservara la simplicidad de

sus predecesores, un par de anos mas tarde, y quiza demasiado, llego el estandar oficial de

la CCITT ( Consultative Committee for International Telegraphy and Telephony ) para el

manejo de mensajes en INTERNET y se llamo X.400 este estandar nunca llego a imponerse

en la INTERNET debido a su complejidad, lo poco flexible de las direcciones y a que llego un

poco demasiado tarde, el hecho es que el estandar de INTERNET para la transferencia de

correo es el SMTP que se usa aun hoy ampliamente en toda la red, con algunas excepciones,

que debido a su formato de transferencia, el SMTP no soporta los caracteres extendidos que

son imprescindible en idiomas como el frances y el aleman, en particular los gobiernos de

Francia y Canada impulsaron el X.400 como estandar ya que se adaptaban mucho mejor a


sus necesidades, ahora estos dos paıses son los unicos que soportan estos protocolos y debido

a esto se necesito la creacion de pasarelas de conversion de un sistema al otro.

Estos protocolos funcionan adecuadamente cuando los destinatarios estan permanente-

mente conectados a INTERNET, pero unos anos despues de la publicacion de los estandares

se hizo mas comun el INTERNET para usuarios domesticos que desde sus casas se conec-

taban, mediante un MODEM, esporadicamente a INTERNET. Estos usuarios tienen un

contrato con un ISP que esta siempre conectado a la red y al llegar un mensaje de correo

para un usuario de ese ISP el servidor de correos del ISP debe guardar el mensaje hasta que

el usuario se conecte y lo solicite. Esta situacion se ilustra en la Figura 2.5.

Figura 2.5: LAN conectada a INTERNET mediante un contrato ISP.

Este ambiente se requirio la especificacion de otro estandar para estos usuarios, de esta

manera aparecio en escena el protocolo de oficina postal, POP, que actualmente se encuentra

en su version 3. Este protocolo permite un interfaz simple para la recepcion de mensajes

y se complementa perfectamente con el SMTP, en la forma en que este ultimo se encarga


del envıo de correo y su transito por INTERNET hasta el servidor de correos destino y el

POP se encarga de el transporte de los mensajes almacenados en el servidor a usuarios que

esporadicamente se conecta a el. Este arreglo podrıa ser algo parecido al de la Figura 2.6.

Hay que notar que no es necesario que los clientes esten conectados permanentemente en

cambio los servidores si.[14]

Figura 2.6: LAN utilizando los protocolos SMTP y POP.


2.1.5. Protocolos de Mensajerıa

EL correo electronico es el servicio de mensajerıa mas utilizado. Por lo tanto, se ofrecen

una gama de protocolos que permiten una facil administracion del enrutamiento del correo

electronico a travez de la red.

SMTP

El protocolo SMTP (Protocolo simple de transferencia de correo) es el protocolo estandar

que permite la transferencia de correo de un servidor a otro mediante una conexion punto a

punto.

El correo electronico se envıa directamente al servidor de correos del destinatario. Este

protocolo funciona con comandos de textos enviados al servidor SMTP (al puerto 25 de

manera predeterminada). A cada comando enviado por el cliente, le sigue una respuesta del

servidor SMTP compuesta por un numero y un mensaje descriptivo[9].

A continuacion se describe como se realiza una solicitud para enviar correos a un servidor

SMTP:

Al abrir la sesion SMTP, el primer comando que se envıa es el comando HELO seguido

por un espacio y el nombre de dominio de su equipo, y despues validado por Enter.

El segundo es el comando “MAIL FROM:”seguido de la direccion de correo electronico

del remitente. Si se acepta el comando, el servidor responde con un mensaje “250 OK ”.

El siguiente comando es “RCPT TO:”seguido de la direccion de correo electronico del

destinatario. Si se acepta el comando, el servidor responde son un mensaje “250 OK ”.

A continuacion el comando DATA, que anuncia el comienzo del cuerpo de mensaje. Si

se acepta el comando, el servidor responde con un mensaje intermediario numerado 354

que indica que puede iniciarse el envıo del cuerpo del mensaje y considera el conjunto

de lıneas siguientes hasta el final del mensaje indicado con una lınea que contiene


solo un punto. El cuerpo del correo electronico eventualmente contenga algunos de los

siguientes encabezados:

• Date (Fecha)

• Subject (Asunto)

• Cc

• Bcc (Cco)

• From (De) Si se acepta el comando, el servidor responde con un mensaje “250

OK ”.

Las especificaciones basicas del protocolo SMTP indican que todos los caracteres enviados

estan codificados mediante el codigo ASCII de 7 bits y que el 8◦ bit sea explıcitamente cero.

Por lo tanto, para enviar caracteres acentuados es necesario recurrir a algoritmos que se

encuentran dentro de las especificaciones MIME:

base64 para archivos adjuntos.

quoted-printable (QP) para caracteres especiales utilizados en el cuerpo del mensaje[19].


Comando Ejemplo Descrpcion

HELO (ahora EH-

LO)

EHLO 192.168.0.2 Identifcacion que utiliza la direccion IP o el

nombre de dominio del equipo remitente.

MAIL FROM: MAIL FROM: usua-

[email protected]

Identificacion de la direccion del cliente.

RCPT TO: RCPT TO: des-

[email protected]

Identificacion de la direccion del destinata-

rio.

DATA DATA mensaje Cuerpo del correo electronico.

QUIT QUIT Salida del servidor SMTP.

HELP HELP Lista de comandos SMTP que el servidor

admite.

Cuadro 2.1: Comandos del protocolo SMTP.

POP3

El protocolo POP (Protocolo de oficina de correos), permite recoger el correo electronico

en un servidor remoto (servidor POP). Es necesario para las personas que no estan permanen-

temente conectadas a Internet, ya que ası pueden conectar sus correos electronicos recibidos

sin que ellos esten conectados.

Existen dos versiones principales de este protocolo, POP2 y POP3, a los que se le asignan

los puertos 109 y 110 respectivamente, y que funcionan utilizando comandos de texto con

algunas diferencias.

Al igual que con el protocolo SMTP, el protocolo POP (POP2 y POP3) funciona con

comandos de texto enviados al servidor POP. Cada uno de estos comandos enviados por el

cliente (validados por la cadena CR/LF) esta compuesto por una palabra clave, posiblemente

acompanada por uno o varios argumentos, y esta seguido por una respuesta del servidor POP

compuesta por un numero y un mensaje descriptivo[7].


Comandos POP3.

El protocolo POP3 administra la autentificacion utilizando el nombre de usuario y la

contrasena. Sin embargo, esto no es seguro, ya que las contrasenas, al igual que los correos

electronicos, circulan por la red como texto sin codificar. En realidad, segun RFC 1939, es

posible cifrar la contrasena utilizando un algoritmo MD5 y beneficiarse de una autenticacion

segura. Sin embargo, debido a que este comando es opcional, pocos servidores lo implementan.

Ademas, el protocolo POP3 bloquea las bandejas de entrada durante el acceso, lo que significa

que es imposible que dos usuarios accedan de manera simultanea a la misma bandeja de

entrada. Una lista de comandos se encuentra en el Cuadro 2.2[7].


Comando Descripcion

USER identification Este comando permite la autentificacion. Debe estar seguido

del nombre de usuario. El comando USER debe preceder al

comando PASS.

PASS password El comando PASS permite especificar la contrasena del usuario

cuyo nombre ha sido especificado por el comando USER previo.

STAT Informacion acerca de los mensajes del servidor.

RETR Numero del mensaje que se va a recoger.

DELE Numero del mensaje que se va a eliminar.

LIST [msg] Numero del mensaje que se va a mostrar.

TOP <messageID> <n> Comando que muestra n lıneas del mensaje, cuyo numero se

da en el argumento. En el caso de una respuesta positiva del

servidor, este enviara de vuelta los encabezados del mensaje,

despues una lınea en blanco y finalmente las primeras n lıneas

del mensaje

UIDL [msg] Solicitud al servidor para que envıe una lınea que contenga

informacion sobre el mensaje que eventualmente se dara en

el argumento. Esta lınea contiene una cadena de caracteres

denominada unique identifier listing (lista de identificadores

unicos) que permite identificar de manera unica el mensaje

en el servidor, independientemente de la sesion. El argumento

opcional es un numero relacionado con el mensaje existente en

el servidor POP, es decir, un mensaje que no se ha borrado.

QUIT El comado QUIT solicita la salida del servidor POP3. Lleva a

la eliminacion de todos los mensajes marcados como eliminados

y envıa el estado de esta accion.

Cuadro 2.2: Comandos del protocolo POP3.


IMAP

EL protocolo IMAP (Protocolo de acceso a mensajes de internet) es un protocolo alter-

nativo al de POP3, pero ofrece mas posibilidades.

Permite administrar diversos accesos de forma simultanea.

Permite administrar diversas bandejas de entrada.

Brinda mas criterios que pueden utilizarse para ordenar los correos electronicos.

Por lo tanto en resumen se puede decir que el correo electronico es un servicio que permite

a usuarios enviar y recibir mensajes de forma rapida y segura mediante sistemas de comuni-

cacion electricos. Por medio de mensajes de correo electronico puede enviarse, no solamente

texto, sino todo tipo de documentos digitales, tando imagenes, audio y hasta video[3].


2.2. Bases de Datos

Una base de datos es un conjunto de datos pertenecientes a un mismo contexto que son

almacenadas para su posterior uso.[11].

Desde el punto de vista informatico, la base de datos es un sistema formado por un

conjunto de datos que estan almacenados en el disco y que permiten el acceso directo a ellos

para que diferentes programas puedan manipular esta informacion a peticion del usuario.[12]

Cada base de datos se compone de una o mas tablas que almacena los respectivos datos.

Cada una de las tablas tiene una o mas filas y columnas. Las columnas almacenan una parte

de la informacion sobre cada elemento que queremos guardar en la tabla, y las filas conforman

un registro.

2.2.1. Caracterısticas de una Base de Datos

Entre las principales caracterısticas de los sistemas de bases de datos se puede mencionar:

Independencia logica y fısica de los datos.

Redundancia mınima.

Acceso concurrente por parte de multiples usuarios.

Integridad de los datos.

Consultas complejas optimizadas.

Seguridad de acceso y auditorıa.

Respaldo y recuperacion.

Acceso a traves de lenguajes de programacion estandar.


2.3. Base de Datos Distribuidas

Un sistema distribuido es una coleccion de datos, construida sobre una red y que pertenece

logicamente, a un solo sistema distribuido.

Este sistema deberıa cumplir las siguientes condiciones.

La informacion de la base de datos esta almacenada fısicamente en diferentes sitios de

la red.

En cada sitio de la red, la parte de la informacion, se constituye como una base de

datos en si misma.

Las bases de datos tienen sus propios usuarios locales, sus propios DBMS y programas

para su administracion.

Estas bases de datos locales deben tener una extension, que gestione las funciones de

sociedad necesarias, la combinacion de estos componentes con los sistemas de adminis-

tracion de base de datos locales, se conoce como Sistema Administrador de Base de

Datos Distribuidas.

Este gestor permite que los usuarios puedan acceder a los datos desde cualquier punto

de la red, como si lo hicieran con los datos de su base de datos local, es decir, para el

usuario, no debe existir diferencia en trabajar con los datos locales o datos de otros

sitios de la red.

Capıtulo III

Modelo del Sistema

CAPITULO III. MODELO DEL SISTEMA 21

A continuacion de dara a conocer el modelo del sistema distribuido, sus componentes y la

explicacion de como funciona detalladamente cada uno de ellos para que ası uniendo todos,

pueda funcionar completamente el sistema.

3.1. Componentes del Sistema

Primero se deben tener algunos requerimientos para que el sistema pueda funcionar de

manera correcta. Por lo cual a continuacion se nombraran sus componentes y una descripcion

de cada uno de ellos.

Existira un nodo receptor, este se encargara de recibir el correo electronico y distribuirlo

de forma equilibrada a los otros nodos para que se lleve a cabo la distribucion equilibrada:

3.1.1. SMTP

El nodo receptor podra transferir un correo electronico a otro servidor, ası como tambien

recibir correos electronicos desde otro servido.

3.1.2. POP

El nodo receptor trabajara con el protocolo POP que permite la captura del correo

electronico para ası proceder a realizar la lectura de este y mas tarde la distribucion.

3.1.3. IMAP

Permite acceder a los mensajes desde cualquier computador que tenga acceso a internet,

el nodo receptor podra realizar esta operacion.


3.1.4. Agente de Entrega de Correos

Permite almacenar los correos electronicos en el buzon de correo correspondiente, esto

quiere decir, que todos los nodos tendran un buzon de correos.

3.1.5. Agente de Usuario de Correo

Permite la lectura y envıo de un correo electronico a traves de una interfaz.

3.1.6. Buzon de Correo

Cada nodo debera almacenar los correos electronicos de los usuarios, aunque la bandeja

sera distinta para todos los nodos en cuanto a contenido y los usuarios de estos correos

podrıan ser cualquiera ya que el sistema esta totalmente distribuido.

3.1.7. Administrador de Usuarios

Un nodo debera administrar unicamente a un usuario, los usuarios no se repetiran en los

nodos, o sea, cada usuario tendra su propio nodo administrador.

3.1.8. Administrador de Discos

El nodo receptor debera poseer informacion de los demas nodos en cuanto a espacio

ocupado en su disco duro, para ası al momento de tener que distribuir un correo, se pueda

realizar de forma distribuida.


3.1.9. Identificador Usuario/Nodo

Los nodos poseen un modulo en el cual les permite identificar para cada usuario, su nodo

administrador.

3.2. Envıo de Correos Electronicos

Para enviar un correo electronico se necesita de una direccion de correo al cual se en-

viara, por ejemplo, [email protected]. Al momento de enviar un correo electronico, el

nodo receptor, debe verificar a que usuario se envıa tal mensaje para ası identificar el nodo

administrador del usuario.

3.2.1. Nodo Receptor

Este nodo sera uno de los que estan incluidos en el sistema distribuido ya que no todos los

nodos trabajan de la misma manera. El nodo receptor es aquel que recibe un correo electroni-

co, y es el que realiza todo el trabajo de verificar donde se encuentra el nodo administrador,

y almacenar el correo electronico en el nodo debido.

3.2.2. Nodo Administrador de Usuarios

Cada nodo administrador contendra una lista de los usuarios a los cuales va a administrar.

En la respectiva lista, el nodo almacena informacion de cada usuarios, los correos que posee y

el lugar donde estan almacenados estos correos electronicos, es decir, en que nodo se encuentra

ubicado. La lista tiene forma de la Figura 3.1.


Figura 3.1: Indice invertido. Los correos electronicos que posee el usuario y los nodos donde

estan almacenados dichos correos.

Para poder identificar cual es el nodo administrador de cada usuario, el nodo receptor

aplica una funcion hashing al nombre se usuario, al aplicar este hashing, da como resultado

el respectivo nodo administrador y ası dirigirse a el para consultar la lista.

Ejemplo de localizar un usuario en su nodo administrador:

Se tiene un nombre de usuario, ‘usuario1’, a este string se le aplicara la funcion hashing,

que consiste en separar los caracteres y sumar sus valores ascii, luego despues de obtener un

valor, realizar la suma de sus dıgitos, esta suma se realizara mientras el dıgito sea mayor a

10, luego de tener un valor de un dıgito se aplica una division por la cantidad de nodos que

existan, por ejemplo, si existen 3 nodos administradores, la division se realiza por 3, para

finalizar el resultado de la division arroja un resto, que pueden ser tres valores posibles, 0, 1

y 2, y esos valores indicaran a que nodo pertenece cada usuario, por ejemplo, 0 = Nodo A,

1 = Nodo B y 2 = Nodo C.


En la Figura 3.2 se mustra un ejemplo de la aplicacin hashing a ‘usuario1’, y ası, detectar

el nodo administrador.

Figura 3.2: Ejemplo de aplicacion de la funcion hashing a ‘usuario1’.

La operacion% 3 quiere decir que existen tres nodos administradores de usuarios, por lo

cual al aplicar este modulo solo se obtendran tres valores posibles. Entonces, como se puede

ver el resultado es 0, esto quiere decir que el nodo administrador del ‘usuario1’ es el nodo A.


3.2.3. Almacenamiento de Correos Electronicos en los Nodos

Para almacenar los correos electronicos, el nodo receptor del mensaje debera consultar por

el espacio ocupado en cada memoria de los discos duros de cada nodo, para ası poder decidir

donde se almacenara el correo recibido, como el sistema debe ser distribuido y equilibrado,

el correo electronico se debe ir almacenando en el nodo que tenga mas espacio libre en su

disco duro, si todos tienen la misma cantidad ocupada, el nodo se escoge de forma aleatoria,

de esta forma se lleva una distribucion de manera balanceada.

A medida que los nodos vayan recibiendo correos, se envıa la informacion necesaria a

todos los nodos de todos los nodos, tales como, capacidad total, espacio ocupado, y espacio

libre si es necesario, ası el nodo receptor puede realizar sin problemas la eleccion del nodo

donde se va a almacenar el mensaje.

Despues de almacenar el mensaje, se envıa la informacion al nodo administrador de usuario

sobre el correo electronico, y el nodo donde se almaceno este, para que ası el nodo adminis-

trador pueda ingresar esta informacion a la lista de ındices invertidos de usuarios.

Basicamente la estructura de envıo de correos electronicos serıa como se muestra a con-

tinuacion:

Se envıa un correo electronico a ‘usuario1’, y este correo es recibido por el nodo A,

como se muestra en la Figura 3.3.


Figura 3.3: El nodo receptor recibe el correo electronico.

El nodo receptor decide cual es el mejor nodo para almacenar el mensaje (el nodo con

menos espacio ocupado en disco duro), de acuerdo a sus registros almacenados de los

diferentes nodos y sus espacios ocupados en disco. Esto se puede visualizar en la Figura

3.4.


Figura 3.4: Detalle de las capacidades de los discos duros de los diferentes nodos.

En este caso el mejor nodo para almacenar el mensaje es el nodo C ya que tiene un

espacio ocupado de 19.4 Gb y es menor a los otros dos nodos A y B que son 21 Gb y

21.3 Gb respectivamente.

Suponiendo que el correo electronico tenia de peso 1 Gb, el detalle de las memorias de

los nodos, despues de haber almacenado dicho correo, quedarıa de la forma como se

muestra en la Figura 3.5.


Figura 3.5: Detalle de las capacidades de los discos duros despues de haber almacenado el

correo electonico.

Luego de almacenar el correo electronico, el Nodo receptor verifica cual es el nodo

administrador del usuario al que se le envio el correo electronico, esto se hace por

medio de la funcion hashing explicada anteriormente, ası le envıa los datos como el

usuario y el Nodo donde se almaceno. De tal manera la lista se modificarıa de la forma

como se ve en la Figura 3.6:


Figura 3.6: Insertando un nuevo correo a la lista de ındices invertidos.

Y de tal manera finaliza el proceso de envıo de un correo electronico y el metodo para

almacenarlo de tal forma que quede el sistema balanceado.


3.3. Lectura de un Correo Electronico

Para leer un correo electronico el usuario necesita ver su bandeja de entrada. En el caso

del sistema distribuido, la bandeja de entrada se puede encontrar ubicada en mas de un nodo

ya que el sistema esta totalmente disperso por el metodo de balanceo.

El primer paso es ubicar donde estan almacenados todos los correos electronicos del

usuario. Para esto el protocolo que se utiliza es el POP (que sera modificado) que permite la

recuperacion de los correos electronicos, pero en nuestro caso, este protocolo debera recuperar

los correos de distintos nodos o servidores para que ası el usuario posteriormente pueda

interactuar con sus mensajes.

Como primer paso se debera verificar cual es el nodo administrador del usuario, esto

se hace aplicando la funcion hashing mencionada anteriormente. Luego que ya se tiene el

nodo administrador, se consulta por los correos electronicos que posee, y en que servidor esta

almacenado. En la Figura 3.7 se puede apreciar la forma de estos pasos.


Figura 3.7: Pasos para la lectura de un correo electronico.

Al momento de saber donde estan almacenados los correos del usuario, procede a actuar

el protocolo POP, que se encarga de captura el o los correos electronicos que se necesitan leer,

estos correos se capturan desde los diferentes nodos. Luego el agente de usuario de correo es

el que se encargara de que el usuario pueda leer el correo mediante alguna interfaz.


3.4. Diagramas del Modelo del Sistema

En la Figura 3.8 se muestra un diagrama de los componentes del sistema y las comunica-

ciones entre ellos.

Figura 3.8: Diagrama del servidor y sus componentes.


En la Figura 3.9 se muestra un diagrama de como serıa el envıo de un correo electronico

con respecto al modelo del sistema.

Figura 3.9: Diagrama del envıo de un correos electronico.


El la figura 3.10 se muestra un diagrama se como serıa la lectura de un correo electronico

con respecto a lo mencionado en el modelo del sistema.

Figura 3.10: Diagrama de la lectura de un correo electronico.

Capıtulo IV

Prototipo del Sistema

CAPITULO IV. PROTOTIPO DEL SISTEMA 37

4.1. Prototipo del Sistema

A continuacion se daran a conocer los dos tipos de prototipos realizados, con nodos

virtuales y con nodos reales.

Para trabajar con los nodos virtuales, se tendra solo un computador, y estos nodos seran

tratados cada uno en un respectivo directorio.

Para los nodos reales, se trabajo con 4 computadores, en el cual el nodo receptor tiene

montado los directorios de los demas para ası poder balancear la carga y distribuir los correos

electronicos.

Estos prototipos estan programados en el lenguaje c++, y compilados con g++ con la

version 4.3.2.

Antes de comenzar con la exlpicacion de los dos prototipos, cabe mencionar que aunque

los dos realicen las mismas funciones, la implementacion es distinta, por lo tanto, los dos

prototipos no son comparables.

4.1.1. Prototipo con Nodos Virtuales

Para este prototipo se trabajara con nodos virtuales, es decir, la aplicacion estara realizada

en un solo computador y los nodos seran trabajados en directorios locales.

Los Servidores

Para comenzar a correr el programa de debe tener en cuenta la cantidad de nodos que

se van a simular y la capacidad de almacenamiento de estos nodos. Estos datos se deben

ingresar en un archivo de configuracion para su posterior lectura.


Ejemplo del archivo de configuracion:

#Cantidad de nodos

5

#capacidad de los nodos en Kbytes, 80Gb = 83886080 app

83886080

Tambien se debe tener previstos un listado de usuarios para ası agregarlos a la aplicacion

y poder trabajar con ellos. Este listado tambien se debe agregar a un archivo.

Teniendo estos dos archivos listos se procede a correr la aplicacion, donde se crearan los

nodos virtuales, que son directorios en el mismo computador. A cada nodo se le asignaran

usuarios, que son los ya ingresados en el archivo. Un usuario se almacenara en su respectivo

nodo administrador, explicado ya en el modelo del sistema, es decir, en cada carpeta creada

para cada nodo, se almacenara un archivo en el cual estan contenidos los respectivos usuarios.

Ejemplo:

Se crean 5 nodos y se tienen 40 usuarios en la lista descritos por el nombre de:

usuario1

usuario2

usuario3

...

usuario40

En los nodos se almacenarıan de acuerdo al hash de la siguiente forma:


Nodo 0/ListaUsuarios Nodo 1/ListaUsuarios Nodo 2/ListaUsuarios

usuario1 usuario2 usuario3








usuario40

Cuadro 4.1: Lista de usuarios almacenados con hash (1).

Nodo 3/ListaUsuarios Nodo 4/ListaUsuarios

usuario4 usuario5

usuario9 usuario11

usuario10 usuario16

usuario15 usuario20

usuario24 usuario25

usuario29 usuario34

usuario33 usuario39

usuario38

Cuadro 4.2: Lista de usuarios almacenados con hash (2).


Hay que recordar que para ello ya se crearon los respectivos directorios para cada nodo.

Tambien se crea una lista local en el nodo receptor, para que ası este nodo pueda realizar

mas rapida la busqueda de un usuario al momento de que se quiera almacenar un correo

electronico o leerlo.

La estructura de los nodos para identificar los servidores se muestra en el Codigo 1.

Codigo 1 Estructura de un nodo servidor

struct Nodo{

IdNodo Id;

Posicion NSig;

Usuarios PUsu;

Kbytes CapacidadGral;

Kbytes CapacidadLibre;

Kbytes Ocupado;

};

La estructura que identifica a un usuario esta dada en el Codigo 2.

Codigo 2 Estructura de un usuario

struct IndiceInvertido{

char *Login;

int id;

Usuarios USig;

Posicion *Arr;

};

Y la lista local al ingresar los usuarios en los respectivos nodos quedarıa de la siguiente

forma:


Nodo 0 —>usuario1 —>usuario6 —>usuario12 —>usuario17 —>usuario21 —>usua-

rio26 —>usuario30 —>usuario35 —>


rio27 —>usuario31 —>usuario36 —>usuario40 —>






rio34 —>usuario39 —>

En dicha lista local, aparte de ingresar los usuarios, se ingresa la capacidad de los nodos.

La capacidad debe estar ingresada en el archivo de configuracion y expresada en Kb, por

ejemplo, si cada nodo tendra 80Gb de capacidad, la lista quedara de la siguiente forma:

Nodo 0 —>83886080

Nodo 1 —>83886080

Nodo 2 —>83886080

Nodo 3 —>83886080

Nodo 4 —>83886080

Al momento de decidir si realizar el almacenamiento y busqueda de usuarios en forma

secuencial o mediante hashing, se opto por la segunda opcion, porque ya que al momento

de almacenar, el tiempo que se obtiene con ambos tipos es practicamente el mismo, como se

muestra en la Figura 4.1.


0

5

10

15

20

25

0 20 40 60 80 100

Tiempo de almacenamiento en microsegundos


Tiempo de almacenamiento

Almacenamiento aplicando HashingAlmacenamineto sin aplicar Hashing

Figura 4.1: Tiempos de almacenamiento.

Pero al momento de realizar la busqueda se obtienen distintos resultados de acuerdo al

metodo de busqueda que se realice.

En la Figura 4.2 se realiza la busqueda de forma secuencial y se puede visualizar que a

medida que se avanza con dicha busqueda de usuarios, el tiempo que transcurre es mayor,

hasta que la cantidad de usuarios buscados sea igual a la cantidad de nodos, luego vuelve a

disminuir el tiempo de busqueda y se repite el mismo proceso.


0

10

20

30

40

50

0 20 40 60 80 100



Tiempo de busqueda

Busqueda sin aplicar Hashing

Figura 4.2: Tiempo de busqueda sin hashing.

En la Figura 4.3 se realiza la busqueda utilizando el metodo de hashing, y como se puede

observar, el tiempo que toma realizar cada busqueda de cada usuario es casi similar y ademas

muy pequeno.


0

10

20

30

40

50

0 20 40 60 80 100



Tiempo de busqueda

Busqueda aplicando Hashing

Figura 4.3: Tiempo de busqueda aplicando hashing.

Luego despues de haber observado los tiempos que tardan ambos tipos de busqueda, se

realiza una comparacion de ellos, como se muestra en la Figura 4.4, y se puede visualizar que

al utilizar la busqueda son el metodo de hashing, disminuye mucho con respecto a la busqueda

secuencial, por lo cual se utilizo el algoritmo que minimiza los tiempos de busqueda.


0

10

20

30

40

50

0 20 40 60 80 100



Tiempo de busqueda


Figura 4.4: Comparacion de tiempos de busqueda.

Al utilizar el algoritmo de hashing, este no realiza la busqueda en los nodos innecesarios,

porque con este metodo, se conoce ya el nodo donde se deberıa encontrar el usuarios a buscar.

Tambien ası para las busquedas infructuosas, como se muestra en la Figura 4.5.


0

10

20

30

40

50

60

0 20 40 60 80 100



Tiempo de busqueda infructuosa


Figura 4.5: Comparacion de tiempos de busqueda infructuosa.

El tiempo de busqueda infructuosa utilizando el metodo de hashing es bastante mas bajo

que el de forma secuencial, ya que este ultimo recorre la lista completamente para encontrar

un usuario, en cambio, al utilizar hashing, solo se realiza la busqueda en el nodo donde podrıa

estar un respectivo usuario, y la lista se reduce mucho.

La funcion de hashing utilizada se muestra en el Codigo 3.


Codigo 3 Funcion Hashing

int Hashing( string str1, int cant_nodos ){

int len,i,sum=0,cop,mod;

std::transform(str1.begin(), str1.end(), str1.begin(),

(int( * )(int))std::tolower);

len = str1.length();

for ( i=0; i<len; i++ ){

sum = sum + int(str1[i]);

}

return sum % cant_nodos;

}

Luego, al tener el servidor funcionando, este solo espera a que se reciba un correo electroni-

co en la cola de correos como se muestra en la Figura 4.6.


Figura 4.6: Envıo de correo electronico.

Al momento que se recibe un correo electronico, el nodo receptor lo almacena en un

archivo que es la cola de correos, desde ahı se captura y se procesa dicho correo, obteniendo

primeramente el usuario al cual se le es enviado.

Luego de obtener el usuario al cual se le envıa el correo electronico, el programa verifica

si tal usuario existe en la lista local, esta busqueda fue explicada anteriormente.

Al momento de que el usuario es finalmente encontrado en la lista, se debe reconocer cual

es el mejor nodo para almacenar el correo electronico, y para que el sistema este balanceado,

el mejor nodo sera el que tenga menos espacio ocupado en el disco. En la lista local que tiene

el nodo receptor, estan almacenados los detalles de los discos de cada nodo, para que ası este

nodo pueda realizar el calculo.

Posteriormente el correo electronico es almacenado en un archivo de texto que es llamado

la bandeja de entrada del usuario, para esto se crea una carpeta con el nombre del usuario en

el servidor apropiado para almacenar el correo electronico. Esto se realiza por cada usuario,

pero solo la carpeta es creada en el nodo si existe algun correo electronico del usuario, de lo

contrario, el usuario no debe tener una carpeta creada.

Luego de almacenar el correo electronico, se vuelve a calcular el espacio ocupado que


tiene el nodo donde fue almacenado el correo electronico, dicha cantidad ocupada se resta a

la capacidad total del nodo actualizando ası la lista local y el detalle de las capacidades.

Ejemplo:

Las capacidades actuales son:

Nodo 0 —>83886080 Kb

Nodo 1 —>83886080 Kb

Nodo 2 —>83886080 Kb

Nodo 3 —>83886080 Kb

Nodo 4 —>83886080 Kb

Se envıa un correo al usuario1.

El mejor nodo para almacenar es el Nodo 0.

Se almacena el correo electronico, y este pesa 16 Kb.

Las capacidades en la lista local quedan de la siguiente forma:

Nodo 0 —>83886064 Kb

Nodo 1 —>83886080 Kb

Nodo 2 —>83886080 Kb

Nodo 3 —>83886080 Kb

Nodo 4 —>83886080 Kb

Luego de actualizada la lista local con las capacidades, se procede a trabajar con la misma

lista local, pero esta vez la lista de usuarios, como se tiene en cuenta, la lista consta de los

nodos creados que son los servidores, y estos nodos contienen una lista de usuarios los cuales


administra. Ahora estos usuarios van a contener apuntadores que indiquen donde tienen

almacenado sus correos electronicos, puede apuntar hacia un nodo, o a todos, dependiendo

de donde tenga el usuario distribuidos sus correos.

Como se menciona anteriormente, cada usuario tiene apuntadores, que en realidad es un

arreglo de punteros. Este arreglo tendra un tamano dependiendo de la cantidad de nodos que

existan, como se ha estado trabajando con 5 nodos, entonces cada usuario tendra un arreglo

de 5 punteros que inicialmente no apuntaran a ningun nodo, como se muestra en la Figura

4.7.

Figura 4.7: Estructura del nodo de un usuario y su arreglo de punteros inicializado.


Figura 4.8: Lista de nodos servidores y usuarios.

En el ejemplo de la Figura 4.8 se muestra una lista de 5 nodos, osea, de 5 servidores que

pueden almacenar correos electronicos, y como se puede ver en la lista, el nodo 0 administra

al usuario1, y el nodo 3 administra al usuario4.

Tambien se puede observar que ambos usuarios poseen correos electronicos, y estos estan

almacenados en diferentes nodos. El usuario1 tiene correos electronicos en el nodo 1 y en el

nodo 2, y el usuario4 posee correos electronicos en el nodo 3 y en el nodo 4.

Entonces, el arreglo de punteros para el usuario1 ya tiene dos apuntadores ocupados y

tres libre, y esto quedarıa como se muestra en la Figura 4.9.


Figura 4.9: Estructura del nodo de un usuario y su arreglo de punteros modificado.

Al terminar de actualizar la lista local con la informacion de los usuarios y donde estan

contenidos sus correos electronicos, esta informacion se almacena en cada carpeta corres-

pondiente a cada nodo. Como se menciono anteriormente, existe un archivo en cada nodo

donde estan contenidos los usuarios a los cuales administra, entonces, en ese mismo archivo

se agregan los nodos los cuales estan almacenados los correos electronicos.

Ejemplo:

Nodo_0/ListaUsuarios

usuario1 0 2


Esto quiere decir que el nodo 0 administra al usuario1, y este usuario posee correos

electronicos en el nodo 0 y en el nodo 2.

Envıo del Correo Electronico

El envıo de correo electronico en este prototipo es muy simple. Se requiere de unos cuantos

comandos para realizar el envıo. Para estos comandos se tomaron como referencia los del

protocolo SMTP mencionado con anterioridad.

Al comenzar a correr el programa aparece un promtp ( se llama prompt al caracter o

conjunto de caracteres que se muestran en una lınea de comandos para indicar que esta a la

espera de ordenes.[18] ).

SMTP >>

Para enviar un correo electronico existe una agrupacion de comandos. Para ver los nombres

de ellos y sus descripciones existe un comando llamado ‘help’.

Ejemplo:

SMTP >> help

ehlo:

Identificacion que utiliza la direccion IP.

mail from:

Identificacion de la direccion del remitente.

rcpt to:

Identificacion de la direccion del destinatario.

data:


Cuerpo del correo electronico.

quit

Salida del servidor.

help

Muestra esta ayuda.

SMTP >>

Los comandos mail from:, rcpt to: y data: son esenciales para enviar el correo electroni-

co, si alguno de estos comandos no se ejecuta o no se ingresan los datos correctamente, el

correo electronico no llegara a su destino.

Lectura del Correo Electronico

Para proceder a realizar la lectura de los correos electronicos, basicamente se necesita solo

el usuario al cual se le quiere leer dichos correos, y nos mostrara cuantos correos se tienen en

la bandeja de entrada, para ası, escoger cual de ellos se quiere leer.

Al comenzar a correr la aplicacion que realiza la lectura de los correos electronicos, esta

esperara a que se ingrese un usuario. Lo siguiente que realiza es obtener el posible nodo donde

se pueda encontrar tal usuarios para ası proceder a buscarlo en la lista de cierto nodo.

La opciones pueden ser que el usuario no exista, por lo cual no se muestra nada, y que el

usuario no posea correos electronicos en su bandeja de entrada.

La otra opcion es que si exista el usuario y que tambien posea correos electronicos, si es

ası, se procede a mostrar la cantidad de correos electronicos que se tienen y detalles como el

remitente, destinatario, la fecha y la hora en que fue enviado dicho correo electronico.


Ejemplo:

usuario1

Tienes 5 Correos

1 [email protected] [email protected] lun feb 15 03:58:10 CLST 2010





Aquı el usuario1 tiene 5 correos recibidos, todos estos de [email protected] el lunes

15 de febrero a las 03:58:10 am.

Como se puede visualizar, cada correo electronico es precedido por un numero, y si se

quiere leer algun correo electronico, se debe ingresar el numero del correo deseado.


4.1.2. Prototipo con Nodos Reales

Para realizar esta aplicacion se necesita que el nodo receptor de los correos electroni-

cos logre acceder a los directorios de los otros servidores, ası poder almacenar los correos

electronicos de los usuarios en cada uno de ellos y mantener el balanceo del sistema.

Para llevar a cabo esto, se utilizo el protocolo samba.

Samba configura directorios Unix y GNU/Linux (incluyendo sus subdirectorios) como

recursos para compartir a traves de la red. Para los usuarios de Microsoft Windows, estos

recursos aparecen como carpetas normales de red. Los usuarios de GNU/Linux pueden montar

en sus sistemas de archivos estas unidades de red como si fueran dispositivos locales, o utilizar

la orden smbclient para conectarse a ellas muy al estilo del cliente de la lınea de ordenes ftp.

Cada directorio puede tener diferentes permisos de acceso sobrepuestos a las protecciones

del sistema de archivos que se este usando en GNU/Linux. Por ejemplo, las carpetas home

pueden tener permisos de lectura y escritura para cada usuario, permitiendo que cada uno

acceda a sus propios archivos, sin embargo, se deberen cambiar los permisos de los archivos

localmente para dejar al resto ver nuestros archivos, ya que con dar permisos de escritura en

el recurso no sera suficiente.[20]

Se instalo samba en cada uno de los servidores, luego se crearon los directorios en el nodo

receptor de correos electronicos para poder montar los demas directorios compartidos.

En el directorio /mnt se creo la carpeta Servidores, y dentro de esa carpeta se crearon los

directorios dependiendo de cuantos nodos existan.

Ejemplo:

Si existen 4 servidores, en el directorio /mnt/Servidores se crean 4 carpetas:

/mnt/Servidores/Nodo_0/





Luego se debe configurar cada servidor para que pueda ser visualizado como compartido

en la red. Para hacer esto se debe establecer un directorio donde se almacenaran los correos

electronicos. Este directorio sera visto a traves de la red como compartido y el nodo receptor

de correos electronicos debera montarlos en las carpetas creadas para ası poder trabajar con

ellos.

Ahora el prototipo del sistema esta listo para ser ejecutado y trabajara realizando las

mismas funciones que el prototipo con nodos virtuales ya que este se desarrolla en directorios

locales, y el prototipo de nodos reales trabaja con directorios compartidos en la red.

4.2. Escalabilidad

La escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica

su habilidad para extender el margen de operaciones sin perder calidad, o bien manejar el

crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse

mas grande sin perder calidad en los servicios ofrecidos[15].

El sistema distribuido de correos electronicos es practicamente escalable. Dando un ejem-

plo, se obtuvo el tiempo de busqueda de usuarios con un sistema de 5 nodos y otro de 10

nodos, los resultados se muestran en la Figura 4.10


0

5

10

15

20

25

0 20 40 60 80 100



Tiempos de busqueda

Busqueda con 5 nodosBusqueda con 10 nodos

Figura 4.10: Tiempo de busqueda con 5 y 10 nodos.

Por lo que se puede apreciar en el grafico, los tiempos de busqueda son practicamente

iguales por lo cual al aumentar la cantidad de nodos en el sistema, no se pierde la calidad de

la busqueda de usuarios.

Capıtulo V

Servicios Propuestos.

CAPITULO V. SERVICIOS PROPUESTOS. 60

5.1. Servidor de Correos Postfix

Postfix es un agente de transporte de correo electronico (MTA) bastante reciente que se

suma a la lista de alternativas al legendario Sendmail. En su diseno han primado factores

como la seguridad, la eficiencia y la facilidad de configuracion y administracion, junto con

la compatibilidad con Sendmail y con otros sistemas de correo. Siendo el correo electronico

hoy dıa una herramienta de trabajo vital en multitud de entornos de trabajo, sustituir los

sistemas actuales por otro nuevo es una decision muy delicada. Se debe garantizar que la

migracion se va a producir sin inconvenientes para los usuarios y con el mınimo tiempo de

parada del servicio. Con Postfix esto es facil de conseguir.

5.1.1. Ventajas de Postfix

Algunas de las virtudes de postfix son:

Diseno modular (no es un unico programa monolıtico).

La seguridad ha sido un condicionante desde el comienzo de su diseno.

Lo mismo cabe decir del rendimiento (seguramente Sendmail no se diseno pensando

que algun dıa habrıa sitios necesitaran procesar cientos de miles o millones de mensajes

al dıa).

Soporte para las tecnologıas mas usadas hoy dıa: LDAP[4], Bases de datos (MySQL),

autentificacion mediante SASL[8], LMTP[5], etc.

Estricto cumplimiento de los estandares de correo electronico (hasta donde se puede

sin dejar a media Internet, que no los cumple, sin poder usar el correo electronico).

Soporte muy bueno para dominios virtuales.

Facilidad de configuracion.


Compatibilidad hacia/desde fuera con Sendmail (.forward, aliases, suplanta mailq, ne-

waliases, /usr/lib/sendmail con versiones equivalentes).

Abundante documentacion, y de calidad.

Facil integracion con antivirus.

Uso sencillo de listas negras.

Soporta de forma nativa el formato de buzones Maildir original de qmail.

Tiene multiples formas de obtener informacion de ‘lo que esta pasando’para resolver

problemas o simplemente, para aprender.

Se pueden lanzar varias instancias de Postfix en la misma maquina con distintas confi-

guraciones, usando cada una distintas direcciones IP, distintos puertos, etc.

Filtrado de cabeceras y cuerpos de mensajes por expresiones regulares.

Utilidades para varias cosas, como gestionar las colas de mensajes.[17]

5.2. Sistema HA Bajo Linux.

¿Porque usar HA?

Siguiendo la ley de Murphy, ”si algo puede fallar entonces fallara!”, en una infraestructura

donde los fallos son importantes porque se deja de dar servicio y mantener ciertos servicios

corriendo en varias maquinas de forma redundante ayuda a evitar estas situaciones.

HA son las siglas de High Availability o Alta Disponibilidad. Se trata de hacer un sistema

redundante a un fallo de hardware (una fuente de alimentacion, un disco duro, una tarjeta

de red...). Uno de los servidores posee un Logical Host formado por una direccion IP, un

volumen de discos y un servidor asociado (HTTP[2], NFS[6], DNS[1]...). Si este servidor tiene

un problema y deja de dar servicio el otro seıa capaz de detectarlo y obtener el Logical Host.


5.2.1. Heartbeat.

Heartbeat ofrece varios beneficios. En primer lugar, permite un tamano de cluster arbitra-

ria. Los servidores no tienen que ser emparejados para conmutacion por error. Por ejemplo, si

se configuran 10 servidores y uno de ellos falla, entonces cualquiera de los 9 restantes pueden

servir como el equipo de conmutacion por error.

En segundo lugar, Heartbeat apoya la supervision de los recursos. Ejemplos de recursos

que desee supervisar activamente incluyen el demonio del servidor PVFS2, la interfaz de

propiedad intelectual, y la conectividad a hardware de almacenamiento.

Por ultimo, Heartbeat incluye un mecanismo de configuracion para expresar las dependen-

cias entre los recursos. Esto puede ser usado para expresar una preferencia por determinados

servidores donde se ejecutan dentro del grupo, o para hacer cumplir que los recursos que

deben iniciarse o detenerse en un orden especıfico.

Requisitos

Hardware.

• Nodos

Cualquier cantidad de nodos puede ser configurado, aunque se necesitan al menos

3, a fin de tolerar un fracaso. Tambien se pueden utilizar cualquier numero de nodos

de repuesto. Un nodo de repuesto es un nodo que no ejecuta ningun servicio hasta

que se produzca un error. Si se tiene uno o mas nodos de repuesto, entonces se debe

seleccionar el primero para ejecutar los recursos en una situacion de conmutacion

por error. Si no se tienen nodos de repuesto (o se han agotado todos los nodos de

repuesto), entonces al menos un nodo tendra que ejecutar dos servicios de forma

simultanea, lo que puede degradar el rendimiento.

• Almacenamiento

El tipo especıfico de hardware de almacenamiento no es importante, pero debe ser

posible asignar un dispositivo de almacenamiento para cada servidor, y todos los


servidores deben ser capaces de acceder a todos los dispositivos de almacenamiento.

• Red.

Heartbeat necesita algun mecanismo para cubrir a un nodo caıdo. Una forma sen-

cilla de hacer esto es conectar cada servidor a una red. Esto permitira a cualquier

servidor dado para enviar un comando a traves de la red a otro servidor.

Software.

• Para esta aplicaion se debe utilizar la version 2.0 o superior de heartbeat.

¿Que sucede durante un error en un servidor?

El siguiente ejemplo ilustra los pasos que se producen cuando un nodo falla:

1. Nodo2 (que se esta ejecutando una aplicacion en una direccion IP virtual) sufre un

fallo.

2. Nodo cliente comienza tiempo de espera / ciclo de reintento.

3. Heartbeat notifica que los servicios que se estan ejecutando en el Nodo2 no estan

respondiendo.

4. Despues de un tiempo transcurrido, los servidores restantes alcanzar el quorum y la

votacion para tratar Nodo2 como un nodo caıdo.

5. Nodo1 envıa un comando para restablecer Nodo2.

6. El Nodo2 bien se reinicia o se queda apagado (dependiendo de la naturaleza de la falla).

7. El comando obtuvo exito, el Nodo5 es seleccionado para reemplazarlo.

8. La direccion IP virtual del Nodo2, lo retoma el Nodo5.

9. Nodo cliente vuelva a intentarlo finalmente tiene exito, pero ahora el trafico de red se

enruta al Nodo5.[16]


5.2.2. Balanceador de Carga con HAProxy/Keepalived

Con este servicio se puede lograr configurar dos nodos en un balanceador de carga en una

configuracion activa/pasiva, utilizando HAproxy y keepalived.

El balanceador de carga situa al usuario entre uno o mas backend con Apache WebServer

que tienen el mismo contenido. El balanceador de carga no solo distribuye la respuesta entre

los dos backends con Apache Server, sino que tambien chequea el estado de los dos servidores.

Si uno de los servidores esta caıdo, todas las solicitudes seran automaticamente redirigidas

a los servidores backends restantes. Ademas de eso, los dos nodos balanceadores de carga se

monitorean mutuamente usando keepalived, si el maestro falla, el esclavo se convierte en

maestro, lo que significa que los usuarios no notaran ninguna interrupcion del servicio.

HAproxy es session-aware ( consciente de la sesion ), lo que significa que se puede utilizar

cualquier aplicacion web que haga uso de sesiones.[10]

Ahora se mostrara un ejemplo y se usaran los siguientes nodos:

Balanceador de carga 1 : bl1.ejemplo.com, direccion IP 192.168.0.100

Balanceador de carga 2 : bl2.ejemplo.com, direccion IP 192.168.0.101

Servidor Web 1 : http1.ejemplo.com, direccion IP 192.168.0.102

Servidor Web 2 : http2.ejemplo.com, direccion IP 192.168.0.103

Tambien se necesitara una direccion IP virtual para bl1.ejemplo.com y bl2.ejemplo.com:

192.168.0.99

En la Figura 5.1 se muestra una pequena configuracion del ejemplo:


Figura 5.1: Configuracion de servidores para HAproxy/Keepalived.

Cabe mencionar que una direcciın IP compartida no es ningun problema siempre y cuando

se esta en una red local donde se puedan asignar direcciones IP como se desee. Sin embargo,

si se desea utilizar esta configuracion con direcciones IP publicas, se necesita encontrar un

proveedor de alojamiento donde se puedan rentar dos servidores (los nodos equilibradores de

carga) en la misma subred, entonces se podra utilizar una direccion IP libre en esta subred

para la direccion IP virtual.

Capıtulo VI

Conclusiones

CAPITULO VI. CONCLUSIONES 67

6.1. Conclusiones

Respecto al trabajo de tıtulo realizado, se dedujeron las siguientes conclusiones:

Se realizo el prototipo de dos formas que realizan exactamente las mismas funciones,

una con nodos virtuales, y otra con nodos reales, ası se logro mostrar como funcionarıa

el sistema implemtentado en su totalidad y las opciones que se puedan utilizar para

que este tenga un buen funcionamiento.

Se reforzo el conocimiento en protocolos de mensajerıa y tambien en el lenguaje de

programacion c++.

Tambien se logro mejorar el tiempo de busqueda de usuarios en sus nodos administra-

dores, ası poder realizar el sistema un poco mas rapido a la hora de querer leer un correo

electronico, ya que como se poseen mas servidores, y los correos estan distribuidos, la

busqueda no es solo en uno de ellos sino podrıa ser en todos.

Se obtuvo el conocimiento de diferentes aplicaciones ya sea para sincronizar compu-

tadores y que trabajen de modo activo/pasivo, y que balanceen el trafico de usuarios.

Se reforzo el conocimiento de servidores de correos, ası tambien se logro proponer

uno de ellos para que el sistema distribuido de correos electronicos tenga una mejor

funcionalidad.

Para finalizar, respecto a los objetivos generales, se puede decir que se cumplio en su

totalidad ya que se logro proponer un sistema distribuido de correos electronicos, rea-

lizando ası un modelo de este, explicando paso por paso cuales serıan los componentes

de este sistema y la funcionalidad de cada uno de ellos, y un prototipo, mostrando

ası como funcionarıa de forma casi real el sistema distribuido de correos electronicos.

Y en cuanto a los objetivos especıficos, se puede decir que tambien se cumplieron ya

que se logro encontrar un servidor de correos como es Postfix que es apropiado para la

realizacion del sistema distribuido de correos electronicos, ya que en general tiene un

alto rendimiento para procesar muchos mensajes, y es facil de configurar, tammbien se


logro encontrar una aplicacion que permitıa sincronizar los computadores y trabajar de

modo activo/pasivo, basicamente se logro que un servidor que otorga algun servicio,

ya sea Apache o MySql, por algun motivo sufre una baja, otro servidor con las mismas

caracterısticas, tome el control, ası el sistema pueda seguir funcionando. Ademas, tam-

bien se realizo un balanceo de usuarios, ası existan dos servidores exactamente iguales,

el trafico de usuarios quede balanceado en los dos servidores.

De acuerdo al trabajo realizado, el sistema distribuido de correos electronicos tiene las

siguientes ventajas y desventajas:

6.1.1. Ventajas

El sistema distribuido de correos electronicos es un buen metodo para las pequenas

empresas que quieran tener su servidor de correos pero tienen varios computadores con

una capacidad muy limitada, y debido a esto, este servicio serıa ideal para ellos, como

tambien ası para las empresas con una inmensa cantidad de usuarios y un gran trafico


Otra punto que se puede mencionar es que el respaldo puede ser individual porque a la

hora de que un servidor tenga perdida de informacion, solo abrıa que recuperar dicha

informacion del servidor fallido.

Este sistema, ademas genera un mejor aprovechamiento en capacidad de almacenamien-

to de correos electronicos ya que son mas los servidores que trabajan en este proceso.

6.1.2. Desventajas

Existe un mayor tiempo de procesamiento, ya que el intercambio de mensajes y los

calculos adicionales son una forma de tiempo extra que no existe en los sistemas cen-

tralizados.


El coste de desarrollo de software es mayor ya que la complejidad que se anade es

necesaria para mantener la coordinacion entre los nodos, esto hace que el desarrollo sea

mas costoso.

6.2. Trabajos Futuros

Implementar en su totalidad el sistema distribuido de correos electronicos cumpliendo

ası los modulos implementados en el prototipo del sistema y las funcionalidades de cada

uno de ellos, tambien tener en cuenta los componentes del sistema mencionados en el

modelo de este.

A la vez tambien instalar y configurar cada una de las aplicaciones propuestas ya que

estas permitiran un mejor funcionamiento del sistema y al mismo tiempo serıan menos

vulnerables a fallos en cuanto a caıdas de servicios que esten corriendo en diferentes

equipos computacionales.

Capıtulo VII

Bibliografıa

Bibliografıa

[1] RFC. Domain name - concepts and facilities. https://www3.ietf.org/rfc/rfc1034.

txt.

[2] RFC. Hypertext transfer protocol - http. http://www.ietf.org/rfc/rfc2616.txt.

[3] RFC. Internet message access protocol. http://tools.ietf.org/html/rfc3501.

[4] RFC. Lightweight directory access protocol (v3). http://www.ietf.org/rfc/rfc2251.

txt.

[5] RFC. Local mail transfer protocol. http://www.ietf.org/rfc/rfc2033.txt.

[6] RFC. Nfs: Network file system protocol specification. http://www.ietf.org/rfc/

rfc1094.txt.

[7] RFC. Post oficce protocol. http://www.ietf.org/rfc/rfc1939.txt.

[8] RFC. Simple authentication and security layer (sasl). http://tools.ietf.org/html/

rfc4422.

[9] RFC. Simple mail transfer protocol. http://tools.ietf.org/html/rfc5321.

[10] WWW. Balanceador de carga de alta disponibilidad. http://www.howtoforge.com/

haproxy_loadbalancer_debian_etch.

[11] WWW. Base de datos. http://es.wikipedia.org/wiki/Base_de_datos.

71

BIBLIOGRAFIA 72

[12] WWW. Base de datos. http://www.monografias.com/trabajos5/basede/basede.

shtml.

[13] WWW. Correo electronico. http://www.monografias.com/trabajos/email/email.

shtml.

[14] WWW. Correo electronico (e-mail). http://www.monografias.com/trabajos/email/

email.shtml.

[15] WWW. Escalabilidad. http://es.wikipedia.org/wiki/Escalabilidad.

[16] WWW. Heartbeat. http://www.pvfs.org/cvs/pvfs-2-7-branch.

build/doc/pvfs2-ha-heartbeat-v2/pvfs2-ha-heartbeat-v2.php#

SECTION00040000000000000000.

[17] WWW. Introduccion a postfix. http://wiki.canaima.softwarelibre.gob.ve/wiki/

index.php/Introducci\%C3\%B3n_a_Postfix.

[18] WWW. Prompt. http://es.wikipedia.org/wiki/Prompt.

[19] WWW. Protocolos de mensajerıa (smtp, pop3 e imap). http://es.kioskea.net/

contents/internet/smtp.php3.

[20] WWW. Samba. http://es.wikipedia.org/wiki/Samba_(programa).

universidad de magallanes. facultad de ingenier´ıa ... · administrador de discos: el nodo...

Documents