User manual | Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica

Universidad de Costa Rica
Facultad de Ingeniería
Escuela de Ingeniería Eléctrica
IE – 0502 Proyecto Eléctrico
Desarrollo de un sistema para la supervisión de
fallas de centrales telefónicas PBX Meridian® a
través de Internet.
Por:
Anthony Cascante Rodríguez
Edgar Guadamuz Arias
Ciudad Universitaria Rodrigo Facio
JULIO del 2005
i
Desarrollo de un sistema para la supervisión de
fallas de centrales telefónicas PBX Meridian® a
través de Internet.
Por:
Anthony Cascante Rodríguez
Edgar Guadamuz Arias
Sometido a la Escuela de Ingeniería Eléctrica
de la Facultad de Ingeniería
de la Universidad de Costa Rica
como requisito parcial para optar por el grado de:
BACHILLER EN INGENIERÍA ELÉCTRICA
Aprobado por el Tribunal:
_________________________________
Ing. Johny Cascante Ramírez
Profesor Guía
_________________________________
Ing. Max Ruiz Arrieta
Profesor lector
_________________________________
Ing. Francisco Rojas Fonseca
Profesor lector
i
ÍNDICE GENERAL
ÍNDICE DE FIGURAS........................................................................................................................................IV
ÍNDICE DE TABLAS ......................................................................................................................................... V
NOMENCLATURA ..............................................................................................................................................VI
RESUMEN...........................................................................................................................................................VIII
CAPÍTULO 1: INTRODUCCIÓN ....................................................................................................................... 1
1.1 JUSTIFICACIÓN ................................................................................................................................................. 1
1.2 OBJETIVOS....................................................................................................................................................... 6
i. Objetivo General .......................................................................................................................................... 6
ii. Objetivos Específicos.................................................................................................................................. 6
1.3 METODOLOGÍA ............................................................................................................................................... 7
CAPÍTULO 2: MARCO TEÓRICO .................................................................................................................... 9
2.1 LA CENTRAL TELEFÓNICA MERIDIAN ............................................................................................................. 9
2.1.1 Funcionamiento y arquitectura ............................................................................................................. 9
2.1.2 Formas de comunicación con la Meridian ......................................................................................... 15
2.1.3 Alarmas y mensajes del sistema .......................................................................................................... 18
2.2 TRANSMISIÓN DE DATOS EN FORMA SERIAL ................................................................................................ 23
2.3 TRANSMISIÓN DE DATOS POR INTERNET ...................................................................................................... 26
2.3.1 Definición red ....................................................................................................................................... 26
2.3.2 Tecnología Ethernet ............................................................................................................................. 27
2.3.3 Definición TCP / IP.............................................................................................................................. 28
2.3.4 Modelo de referencia iso de 7 capas................................................................................................... 29
2.3.5 Dispositivos para el interfuncionamiento de INTERNET.................................................................. 31
2.3.6 El X.25 y su relación con el modelo ISO ............................................................................................ 33
2.3.7 El modelo de estratificación por capas de TCP/IP de Internet......................................................... 34
2.3.8 Estratificación por capas en un ambiente de Internet TCP/IP ......................................................... 37
2.3.9 Estratificación por capas en presencia de una subestructura de red ............................................... 38
2.3.10 Como funciona TCP/IP...................................................................................................................... 40
2.3.11 Administración TCP/IP...................................................................................................................... 41
2.3.12 ¿Qué es internet?................................................................................................................................ 42
2.3.13 Servicios de internet a nivel de aplicación:...................................................................................... 42
2.3.14 Servicios de internet a nivel de red ................................................................................................... 45
2.3.15 Protocolos para la gestión de redes.................................................................................................. 47
2.4 LA INTERFAZ SOCKET ................................................................................................................................... 47
CAPÍTULO 3: DISEÑO DEL SISTEMA DE TRANSMISIÓN DE DATOS.............................................. 54
3.1 REQUISITOS DE DISEÑO ................................................................................................................................. 55
3.2 ESCOGENCIA DE LA LÍNEA A SEGUIR ............................................................................................................ 57
3.4 CONFIGURACIÓN DE LA CENTRAL MERIDIAN 1. .......................................................................................... 58
3.5 DISEÑO DEL PROGRAMA PARA TRANSMITIR DATOS ..................................................................................... 59
3.5.1 ESPECIFICACIONES DEL COMPORTAMIENTO DEL PROGRAMA .................................................................. 60
ii
3.5.2 DISEÑO DEL MÓDULO DE CAPTURA DE MENSAJES DE LA MERIDIAN 1. ................................................... 63
3.5.3 DISEÑO DEL MÓDULO DE IDENTIFICACIÓN Y REGISTRO DE LOS MENSAJES. ............................................ 65
3.5.4 DISEÑO DEL PROCESO SOCKET CLIENTE.................................................................................................... 66
3.5.5 DISEÑO DEL MÓDULO SERVIDOR ............................................................................................................... 67
3.5.6 DISEÑO DEL MÓDULO PARA ESCRIBIR EN LA BASE DE DATOS .................................................................. 67
CAPITULO 4: DISEÑO DE LA APLICACIÓN WEB................................................................................... 69
4.1 MÓDULO INDEX.HTML .................................................................................................................................. 70
4.2 MÓDULO LOGIN.CGI ...................................................................................................................................... 71
4.3 MÓDULO CABEZA.CGI ................................................................................................................................... 72
4.4 MÓDULO LEERLOG.CGI ................................................................................................................................. 73
CAPÍTULO 5: GUÍA PARA LA INSTALACIÓN Y EL USO ...................................................................... 75
5.1 REQUISITOS DE HARDWARE Y SOFTWARE ................................................................................................... 75
5.2 INSTALACIÓN DEL SISTEMA .......................................................................................................................... 77
5.3 USO DE LA APLICACIÓN WEB ........................................................................................................................ 79
CAPÍTULO 6: CONCLUSIONES Y RECOMENDACIONES ..................................................................... 83
BIBLIOGRAFÍA ................................................................................................................................................... 86
APÉNDICES........................................................................................................................................................... 87
ANEXOS: NEMÓNICOS DE LOS MENSAJES DE ERROR. ..................................................................... 88
iii
ÍNDICE DE FIGURAS
Figura 2.1 Central PBX en el contexto de la red telefónica pública. ................................... 10
Figura 2.2 Arquitectura básica de la Meridian. ................................................................. 13
Figura 2.3 Acceso local y acceso remoto.......................................................................... 16
Figura 2.4: Conector DB9 típico....................................................................................... 23
Figura 2.5 Buffers presentes en la transmisión serial. ....................................................... 25
Figura 2.6: Representación de una trama de Ethernet........................................................ 28
Figura 2.7 Modelo por capas ISO. .................................................................................... 30
Figura 2.8: Dispositivos para el funcionamiento de Internet.............................................. 32
Figura 2.9 Capas conceptuales del TCP/IP ....................................................................... 35
Figura 2.10 Estratificación por capas en una Internet con TCP ......................................... 37
Figura 2.11 Proceso de comunicación entre sockets.......................................................... 53
Figura 3.1 Diferentes esquemas de conexión .................................................................... 54
Figura 3.2: Diagrama funcional básico del sistema de transmisión.................................... 62
Figura 4.1: Esquema de funcionamiento de la aplicación Web.......................................... 69
Figura 4.2: Captura de pantalla de index.html................................................................... 70
Figura 4.3: Diagrama ASM de login.cgi ........................................................................... 71
Figura 4.4: Captura de pantalla de cabeza.cgi ................................................................... 72
Figura 4.5: Diagrama ASM de leerlog.cgi ........................................................................ 74
Figura 5.1: Página de inicio.............................................................................................. 80
Figura 5.2: Ejemplo de ordenamiento por defecto............................................................. 80
Figura 5.3: Opciones de búsqueda o filtrado..................................................................... 81
Figura 5.4: Característica a filtrar ..................................................................................... 81
Figura 5.5: Opciones de ordenamiento ............................................................................. 82
Figura 5.6: Ejemplo de una búsqueda ............................................................................... 82
Figura 5.6: Resultado de la búsqueda de ejemplo ............................................................. 82
iv
ÍNDICE DE TABLAS
Tabla 2.1 Módulos principales de una central digital......................................................... 12
Tabla2.2: Designación de pines para un conector DB9 RS-232......................................... 24
Tabla 4.1: Parámetros y sus posibles valores en leerlog.cgi .............................................. 73
v
NOMENCLATURA
CGI
Common Gateway Interface.
DRAM
Dinamic Random Access Memory.
DTMF
Dual Tone Multifrequency.
DTR
Digitone Receiver.
DCE
Data Comunication Equipment.
DTE
Data Terminal Equipment.
HTTP
Hiper Text Transfer Protocol.
HTML
Hiper Text Mark-up Languaje.
IP
Internet Protocol.
LAPW
Limited Access Password.
MSC
Mini System Controller.
PBX
Private Branch Exchange.
vi
PPP
Point to Point Protocol.
ROM
Read Only Memory.
SDI
Serial Data Interface.
SSC
Small System Controller.
TCP
Transfer Control Protocol.
TDS
Tone and Digit Switch.
TTY
Tele Typer Terminal.
UART
Universal Asyncronous Receiver/Transmiter.
vii
RESUMEN
Este proyecto consistió en el diseño de un sistema para la transmisión y presentación de
las fallas ocurridas en centrales telefónicas a través de Internet. El sistema está formado por
tres partes principales, encargadas de leer datos del puerto serie, transmitir datos por
Internet y presentar esos datos en una página Web, respectivamente.
Para la transmisión de datos por Internet se utilizaron sockets. Los datos recibidos en el
servidor se almacenaron en archivos de texto planos. Para la presentación de las bases de
datos en una página Web se utilizó un conjunto de CGI que brindan herramientas para
buscar, ordenar y restringir la información.
viii
CAPÍTULO 1: Introducción
1.1 Justificación
Las telecomunicaciones han sido una parte fundamental en la vida del ser humano. La
reducción de los tiempos de transmisión de datos, así como la capacidad de los medios para
transportar cada vez más información han sido un reto esencial para la tecnología.
El desarrollo de las civilizaciones, con el consecuente aumento en las actividades
comerciales, científicas, culturales y académicas acrecentó la necesidad de buscar medios que
permitieran establecer comunicación rápida entre grandes distancias.
Con el descubrimiento de la electricidad en el siglo XVIII se comenzó a buscar formas
para utilizar señales eléctricas en la transmisión de mensajes, pero fue hasta 1837 que
Charles Wheatstone y William F. Cooke patentaron el telégrafo eléctrico en Gran Bretaña, al
mismo tiempo que Samuel Morse lo hacía en Estados Unidos. Morse también desarrolló un
código telegráfico, basado en puntos y rayas, que lleva su nombre.
La telegrafía se desarrolló con el pasar de los años. En 1874, Thomas Edison desarrolló
la telefonía cuádruple, la cual permitía enviar y recibir simultáneamente dos mensajes. Como
resultados importantes de estas técnicas están el teletipo, el télex y el facsímil.
El siguiente reto fue intentar transmitir voz por medio de señales eléctricas. Hubo
algunos intentos que permitieron transmitir vibraciones sonoras, pero el primer teléfono
eléctrico propiamente dicho fue inventado por Alexander Graham Bell, en 1876.
El teléfono revolucionó nuestro concepto de comunicación, permitiendo establecer
conversaciones con personas que se encuentran a mucha distancia, en un tiempo bastante
corto.
En un principio, el funcionamiento del sistema telefónico suponía la existencia de una
operadora humana encargada de realizar las conexiones deseadas entre abonados. Así, para
realizar una llamada, primero debía comunicarse con la operadora, decirle con quién se
1
deseaba hablar y entonces la operadora transfería la llamada manualmente. Posteriormente
aparecieron las primeras centrales telefónicas automáticas basadas en el sistema de pulsos.
Este sistema consistía en un disco marcador, el cual poseía un sistema mecánico, que abría y
cerraba un conmutador eléctrico para marcar el número deseado, de acuerdo con el número
de giros que daba el disco. Esto producía una serie de pulsos, de amplitud igual al voltaje
suministrado por la central, generalmente 50V.
Las centrales entonces tenía equipos contadores de pulsos que determinaban el número
que se deseaba marcar. Estas centrales se conocían como centrales automáticas de
conmutación y los teléfonos de esta tecnología son conocidos como del tipo 500. Sus
principales inconvenientes eran el elevado costo de mantenimiento y la lenta marcación.
Ya para mediados del siglo XX se hizo posible la creación de otro sistema telefónico,
basado en tonos. Para realizar la marcación se cuenta con conjunto de botones, uno por cada
número y símbolo. Los botones están dispuestos en un arreglo de filas y columnas, donde
cada fila corresponde a una frecuencia baja y cada columna está asociada a una frecuencia
alta. De esta manera al oprimir un botón se transmite un único par frecuencia bajafrecuencia alta.
Las facilidades de amplificación del transistor permitieron que los tonos transmitidos
fueran de baja potencia en vez de los pulsos de marcado de gran potencia. Esta transmisión
se conoce como sistema de tonos y los aparatos telefónicos fueron denominados del tipo
2500.
Las centrales se diseñaron entonces para recibir tonos, sin embargo, dado que la mayoría
de las centrales en los sistemas telefónicos eran de pulsos y aún existían muchos teléfonos
tipo 500, las centrales se construyeron para que también continuaran funcionando con el
sistema de pulsos. Además, dado que aún existían muchas líneas que no admitían tonos, los
teléfonos 2500 cuentan con un interruptor que permite variar entre el sistema de marcación
por pulsos y por tonos.
2
Por último aparecieron las centrales telefónicas digitales, las cuales están sustituyendo a
sus similares analógicas. Estas centrales están controladas por una computadora, lo cual ha
mejorado notablemente los tiempos de procesamiento de las llamadas lo que permite
manejar simultáneamente muchas llamadas, por multiplexación en el tiempo (TDM). Así
mismo, la red telefónica permitió el transporte simultáneo de voz y datos, facilitando la
comunicación entre computadoras y otras terminales alejadas entre sí. La señal analógica de
la voz es digitalizada en la central, transmitida por medios de alta capacidad y transformada
de nuevo a analógica cuando llega a la central de destino. Todo esto se realiza por medio de
software almacenado una computadora. La conexión entre la central y el abonado sigue
siendo analógica, sobre cables de cobre. Sin embargo, en algunas ciudades grandes ya se
utiliza fibra óptica.
Junto a las centrales digitales se ha introducido una serie de servicios adicionales a lo que
son llamadas, como es el caso de identificación de llamadas, llamada en espera, correos de
voz, conferencia (llamadas multiusuario), transferencia de llamadas, etc. Además, la
confiabilidad del sistema se ha incrementado, al incluir duplicidad en los equipos.
Sin embargo no han desaparecido las fallas que pueden ocurrir en una central, ya sea por
errores internos en el software o el hardware de la máquina, errores externos, provenientes
de la empresa que suministre energía eléctrica o la red telefónica pública o incluso errores
debido a una mala configuración de la central u operaciones incorrectas se intentaron hacer.
Las centrales digitales, como cualquier computadora tienen puertos de salida y entrada
de datos por los cuales se introducen instrucciones para programar la central y salen los
mensajes de los resultados de las operaciones realizadas, el nombre de un dato solicitado
(prompt) o mensajes de alerta cuando han ocurrido fallas.
Para poder acceder a estos mensajes generalmente se conecta una computadora a uno de
estos puertos y mediante un programa como Hiperterminal, es posible comunicarse con la
central, pero evidentemente se debe estar muy cerca de la misma.
3
Existe otra forma que permite estar a una distancia mayor. Consiste en poner un
MODEM a la salida de la central y otro MODEM en la computadora terminal. Esta forma
puede ser útil, sin embargo, el acceso a la central por ese puerto puede lograrse únicamente
con la computadora conectada al otro extremo.
Además es posible conectar la central a la red local de la empresa propietaria. De esta
forma la central se convierte en un elemento más de la red y podría ser accedido desde
cualquier computadora de la misma. Más aún, si la red tiene salida a Internet, el acceso
puede realizarse en forma remota, por medio de los protocolos TCP/IP.
Internet es una red de redes global, lo cual quiere decir que potencialmente se podría
tener acceso a una central conectada a la red desde cualquier lugar del planeta. Internet
funciona bajo el modelo cliente-red-servidor, donde los datos viajan en paquetes a través de
la red, desde el cliente hasta el servidor y viceversa. La “red” contiene miles de enrutadores
que se encargan de direccionar los paquetes hacia su destino, gracias a la dirección IP
incluida en la cabeza de cada paquete.
El hecho de conectar una central a la red y desarrollar un sistema de supervisión de la
misma permitiría a los administradores y técnicos tanto de la empresa propietaria de la
central como de la compañía encargada de dar soporte consultar si hay fallas o no sin
necesidad de estar cerca de la central.
Este trabajo pretende realizar tal conexión a través de una página en Internet, por lo que
la comunicación con la central se realizaría a través de un servidor. La central será
específicamente una central privada (PBX) de tipo Meridian, que es una marca registrada de
la empresa Nortel.
La primera central totalmente digital de Nortel se llamó SL-1 y empezó a producirse en
1975. Cuatro años después se introdujo la central DM-100, que soportaba hasta 100 000
líneas. La central Meridian se patentó en 1988 como una continuación de la SL-1 para China
y rápidamente se comercializó en todo el mundo.
4
Este proyecto pretende aportar una herramienta tecnológica para el personal técnico,
que permita agilizar la detección y solución de fallas en las centrales Meridian. Como
resultado se espera reducir el tiempo de solución de las fallas, ya que los técnicos tendrán
cierta información sobre el error ocurrido antes de llegar al lugar donde se produjo.
Alternativamente, dependiendo de la falla, la solución podría enviarse vía teléfono o correo
electrónico, lo cual supone tiempos mucho menores.
Además, la realización de este proyecto es el primer paso en un proceso de
automatización que se podría iniciar. El sistema podría adaptarse para brindar un servicio
similar a otros equipos, supervisar no sólo fallas de las centrales sino también registros de
tráfico y otros parámetros de desempeño, así como acceder y modificar la configuración de
la máquina. Incluso podría implementarse un sistema de solución automática para algunas de
las fallas.
El proyecto cuenta con el apoyo de la empresa Telectro, distribuidora en nuestro país
de productos Nortel, la cual manifestó su interés en el desarrollo del mismo y facilitó la
documentación técnica específica, así como el uso de centrales Meridian para realizar
pruebas. Además, Telectro cuenta con un sitio Web donde puede montarse el sistema y
observar su comportamiento y aceptación.
5
1.2 Objetivos
i.Objetivo General
Diseñar un sistema de supervisión que permita detectar las fallas de las centrales
telefónicas PBX Meridian a través de Internet.
ii. Objetivos Específicos
•Conocer el funcionamiento de las centrales telefónicas, profundizando en las centrales PBX
Meridian.
•Presentar la forma en que se comunica la central Meridian y determinar las variables que se
desean supervisar.
•Estudiar los principios fundamentales de la transmisión de datos en una red de
computadoras e Internet, protocolos TCP/IP, HTTP, fundamentos de los servidores y
otros.
•Diseñar un sistema de transmisión de datos encargado de enviar los datos de la central al
servidor.
•Diseñar una aplicación Web para la comunicación servidor-usuario que sea amigable,
segura, que funcione en tiempo real y que avise automáticamente la ocurrencia de fallas.
6
1.3 Metodología
Para realizar el diseño propuesto se siguió la siguiente metodología:
•Recopilación de información bibliográfica acerca de los aspectos generales de las centrales
telefónicas. Toda la búsqueda de la información se realiza en artículos publicados en libros,
revistas y publicaciones en Internet.
•Recopilación de información bibliográfica acerca de los aspectos específicos de las centrales
Meridian. Para esto se revisa la información técnica dada por el fabricante, Nortel.
•Investigación bibliográfica de los protocolos de transmisión TCP/IP y HTTP, así como los
fundamentos de las redes de computadoras, los servidores e Internet. Se utilizan libros
especializados, libros de redes en general y sitios de Internet.
•Para realizar el diseño del programa agente se redactó primeramente un planteo escrito de
las restricciones de diseño y características que debe tener. Posteriormente se dibujaron
diagramas de bloques, diagramas ASM y cualquier otro tipo de representación gráfica del
algoritmo que se debe implementar. Por último se escogió un lenguaje de programación y se
escribió un código fuente. Fue necesario realizar consultas sobre el lenguaje específico de
programación para poder redactar el código fuente. Esto se hizo en libros especializados y
en sitios de Internet. Finalmente se compiló el programa y se realizaron algunas pruebas y
simulaciones.
7
•En el diseño de la aplicación Web se siguió una metodología similar. Primero se redactó un
planteo escrito, luego se dibujaron esquemas y por último se escogió un editor de HTML, y
se escribió el código de la página.
•Redacción de un informe escrito del proyecto, de acuerdo con las especificaciones
expuestas en el programa del curso, incluyendo una revisión de los capítulos I y II, entrega
y revisión de un avance, un borrador final y una versión final del trabajo. Además se realizó
una presentación para la defensa del proyecto.
8
CAPÍTULO 2: Marco Teórico
En este capítulo se hace una introducción a los fundamentos teóricos que sustentarán el
diseño que se desea realizar. Se tratan diversos temas que deben ser tomados en cuenta,
comenzando con aspectos relativos a la central Meridian, su funcionamiento, arquitectura,
formas de comunicación y formato de los mensajes de error. En segundo lugar se estudian
conceptos relacionados con la transmisión de datos por Internet, como son la arquitectura
de la red, servidores, enrutadores y protocolos de transmisión. Se hace énfasis en el
protocolo TCP/IP y la interfaz socket.
2.1 La central telefónica Meridian
Meridian 1 es el nombre de la familia de centrales telefónicas PBX de Nortel. Existen
varios modelos, llamados opciones, de los cuales los más populares son: 11C mini, 11C,
61C, 81C y Succession. Cada una presenta diferentes características en cuanto a capacidad
y tamaño, sin embargo todas comparten una arquitectura muy similar y muchos de sus
componentes son compatibles entre sí.
2.1.1 Funcionamiento y arquitectura
La red telefónica tiene conectados una cantidad inimaginable de teléfonos en todo el
mundo. Cuando una persona levanta el auricular para hablar con otra desea establecer una
conexión física con la línea de la otra persona. Si tal conexión fuera dedicada, es decir, con un
par de cables que siempre están disponibles para realizar la conexión, la cantidad de cables
necesarios para comunicar a todos los usuarios del sistema entre sí sería práctica y
económicamente prohibitiva.
9
En lugar de eso, cada usuario está conectado a una central telefónica que le permite
comunicarse con cualquier otro usuario sin necesidad de una conexión dedicada. Una central
telefónica, básicamente, es un equipo que permite realizar una conexión temporal de voz
entre dos o más aparatos conectados a ella. En el proceso de establecer la conexión, una
central podría tener que comunicarse con otra central, ya sea directamente o por medio de
una o varias centrales de paso. Si la llamada es internacional, la conexión debe incluir una
central internacional. En el caso de las centrales privadas (PBX) la conexión puede ser
interna (con una oficina del mismo edificio, por ejemplo) o bien externa, con la red pública
(si existe conexión).
Figura 2.1 Central PBX en el contexto de la red telefónica pública.
Para realizar su función, la central lleva a cabo un proceso de conmutación en el que se
utiliza multiplexación por división en el tiempo (TDM). Esto permite transmitir una gran
10
cantidad de conversaciones por el mismo medio físico. Se dice que la conexión es temporal
porque una vez finalizada la conversación la central libera la conexión. Con esto es posible
establecer luego una nueva conexión entre otro par de usuarios.
Dado que la voz es una señal analógica, antes de que una llamada pueda ser procesada
debe haber un proceso de conversión de analógico a digital (con sus correspondientes
subprocesos de muestreo, cuantificación y codificación PCM).
En el proceso de comunicación por teléfono existe una convención (que funciona como
interfaz máquina – hombre) para que el usuario pueda indicarle a una central con quién desea
hablar, así como para que la persona a la que se llama sepa cuando alguien lo llama. Se
denomina “abonado A” a la persona que intenta establecer una conexión y “abonado B” a la
persona que recibe la llamada.
Para que el abonado A le indique a la central el número telefónico del destino, éste
levanta su auricular y espera hasta escuchar el tono de invitación a marcar. A continuación
marca el número telefónico y espera la respuesta de la central, que pueden ser dos: tono de
ocupado o tono de timbrado. Si el abonado B no tiene la línea ocupada, escuchará que su
teléfono timbra y entonces lo contesta. En ese momento la central establece la conexión y se
desentiende de la misma.
Con base en la descripción anterior, es posible distinguir los módulos principales con
los que debe contar la central digital. En la siguiente tabla se enumeran estos módulos y se
explica brevemente su función.
11
Tabla 2.1 Módulos principales de una central digital.
Nombre Genérico
Alimentación eléctrica
Denominación Meridian
Power equipment
Descripción
Fuente de poder AC/DC,
baterías, UPS.
Generador de tonos y cadencias Tone and digit switch (TDS)Genera los diferentes tonos de
invitación a marcar, llamando,
línea ocupada.
Generador de timbrado
Ring generator
Encargado de generar la señal
que indica al usuario que tiene
una llamada.
Unidad de control
Common equipment
Realiza el procesamiento,
control, ejecución del software
y funciones de memoria del
sistema.
Red de conmutación
Network equipment
Realiza
funciones
de
conmutación
para
interconectar puertos del
equipo periférico.
Equipo periférico
Periferal equipment
Son las interfaces hacia puntos
de conexión al mundo externo
(terminales,
teléfonos
y
troncales).
Supervisión y control
System monitor
Supervisa variables como
voltaje, potencia, temperatura,
etc.
Circuitos de conferencia
Conference
Sistema que permite establecer
comunicación entre más de
dos teléfonos.
Marcación DTMF (dual tone Digitone receiver (DTR) Encargado de la interpretación
multifrequency)
de las señales de marcación
por tonos.
12
Unidad de control
Procesamiento, memoria, control
Red de Conmutación
Circuitos conmutadores
Fuente de Poder
Equipo Periférico
Líneas, troncales e interfaces de datos
Terminales
Teléfonos, Operadoras y equipos de datos
Figura 2.2 Arquitectura básica de la Meridian.
Estos módulos son tarjetas electrónicas que van montadas en un gabinete. El gabinete
presenta una sección para las tarjetas y otra para el cableado necesario. Hay gabinetes
principales y pueden haber gabinetes de expansión. La fuente de alimentación AC/DC, el
módulo de supervisión y control y el generador de timbrado van juntos en un mismo
módulo, llamado simplemente fuente. Todos los gabinetes deben tener su propia fuente.
13
La unidad de control, la red de conmutación, el DTR, el TDS, la memoria, los puertos de
entrada/salida y los circuitos de conferencia van juntos en otra tarjeta, llamada SSC (Small
System Controller) o MSC (Mini System Controller , en el caso de la opción 11C mini),
que corresponde a la CPU.
En el gabinete hay campos para insertar módulos adicionales como son las tarjetas de
expansión por fibra, el módulo de correo de voz (Meridian Mail), tarjetas para troncales
(líneas de salida a la red pública), tarjetas para líneas digitales y analógicas, etc.
El software que controla las operaciones de la central se denomina X11, que es un
sistema operativo multitarea. Como complemento está la base de datos que contiene toda la
información sobre números de puerto, registros de troncales, números de extensión y
configuraciones. Sobre el X11 se incorporan paquetes adicionales para realizar funciones
más específicas. Todo el software está almacenado en una memoria DRAM. Hay también
una memoria tipo ROM programable donde está el firmware, o programas basado en
microinstrucciones a nivel lógico. Existe además otra memoria tipo flash suplementaria para
guardar una copia de respaldo de los datos. Esto permite recargar el sistema rápidamente y
acceder en forma rápida a los programas de recubrimiento.
Algunos programas corren permanentemente, otros tienen horarios establecidos por el
usuario. Los programas que siempre están presentes en la memoria se llaman programas
residentes (algunos programas residentes están ubicados en la ROM y otros se cargan
automáticamente a la DRAM en el arranque), mientras que los programas no residentes
deben cargarse para su ejecución en rutinas de medianoche (se ejecutan a las 24 horas,
cancelando la ejecución de cualquier otro programa), rutinas de fondo (que corren cuando
ningún otro programa está cargado en el área de programa) o diagnósticos interactivos. Por
esta razón, los programas no residentes se denominan overlays o loads. Éstos se identifican
por un título seguido de un nemónico y un número, por ejemplo Trunk Diagnóstic -LD 36.
Cuando ya no se necesita más un programa no residente, éste es removido de la memoria.
14
Aparte de la memoria, la SSC tiene otros componentes, entre los que se encuentran las
interfaces para tarjetas de expansión, un socket PCMCIA, 32 canales de conferencia, 30
canales de TDS, tres puertos seriales y una para conexión a Ethernet de 10Mbps, entre
otros. Como seguridad se incluyó un dispositivo (security device) sin el cual el X11 no
funciona.
Hay otros elementos que permiten que el sistema sea menos vulnerable a fallas externas.
Uno de estos elementos es el denominado Power Fail Transfer Unit (PFTU), el cual se
encarga de conmutar las troncales hacia teléfonos analógicos de emergencia, cuando la central
deja de funcionar. La activación del PFTU puede hacerse por diferentes formas: por una
falla en la alimentación, una falla en la CPU, falla en la conexión de fibra (en el caso de
gabinetes de expansión), porque la CPU envió una señal o por activación manual. Un banco
de baterías o UPS es otro elemento de protección que permite que el sistema siga
funcionando aún si se interrumpe la alimentación AC. Este elemento se coloca fuera del
gabinete. Por último se mencionará que hay un termostato que se abre si la temperatura del
sistema alcanza los 80 ºC.
2.1.2 Formas de comunicación con la Meridian
La familia Meridian 1 utiliza un sistema de indicador – respuesta para comunicarse con
el usuario. El sistema imprime un indicador en la Terminal Teletipo (TTY) del sistema y el
usuario escribe una respuesta en la TTY para contestar al indicador. Para realizar tal
comunicación, debe utilizarse los siguientes dispositivos de entrada/salida en lugares locales
o remotos:
•Terminal TTY o VDT como dispositivo de entrada/salida.
•Impresora compatible RS-232 C sólo como dispositivo de salida.
•Aparato de teléfono de mantenimiento como terminal de entrada/salida.
15
•Cualquier terminal que posea las siguientes características:
-Interface: RS-232 C
-Código: ASCII
-Velocidad: 300, 600, 1200, 4800, 19200 baudios.
-Corriente de Bucle: 20mA
Tanto para acceso local como para acceso remoto, las terminales se conectan al sistema
a través de paquetes de interface de datos Serie (SDI). Para dispositivos de acceso remoto
(cualquiera ubicado a más de 15m de la central) debe utilizarse módems y una línea
telefónica entre la terminal y la SDI, como se muestra en la siguiente figura.
Figura 2.3 Acceso local y acceso remoto
Para una correcta operación, las terminales usadas para comunicarse con las opciones
51C, 61C, 81 y 81C deben configurarse a 7 bits de datos sin bit de paridad, baudeaje de
9600, un bit de parada y XON.
16
Antes del release 19 sólo un dispositivo podía comunicarse con el sistema. Si se
intentaba ingresar al sistema cuando alguien ya lo había hecho implicaba sacar del sistema al
usuario que ya había ingresado. Después del release 19 se implementó la capacidad
multiusuario, con lo que varios usuarios pueden ingresar simultáneamente a través de los
diferentes puertos de la máquina.
Sin embargo, sólo una terminal a la vez puede utilizar el área de overlay, es decir, sólo
una terminal a la vez puede cargar programas no residentes, aunque varias terminales
pueden recibir simultáneamente los mensajes de salida del sistema. Una terminal puede ser
configurada como de sólo entrada, sólo salida o entrada y salida.
El sistema cuenta con un mecanismo para evitar que los puertos TTY afecten la correcta
operación del equipo. Si se detecta una interferencia excesiva o bien un conjunto de
caracteres inválidos en un puerto, ese puerto queda bloqueado por cuatro minutos, luego de
los cuales se rehabilita automáticamente. Si se reincide 3 veces, la rehabilitación deberá ser
hecha en forma manual.
Para poder conectarse con la Meridian 1 a través de un puerto serie es necesario
identificarse, por medio de un loggin y un password. Es posible crear un password con
acceso limitado (LAPW, limited access password) que defina el acceso deseado a programas
específicos, así como que el password permita sólo imprimir.
La Meridian 1 tiene soporte para Ethernet usando el protocolo punto-a-punto (PPP), el
cual forma parte del protocolo TCP/IP. Esto brinda al sistema una interface de red que
permite a aplicaciones usar TCP/IP para acceder al sistema de forma remota.
Aunque PPP está diseñado tanto para comunicaciones síncronas y asíncronas, sólo las
asíncronas son admitidas por la Meridian.
El sistema además admite una única conexión PPP al mismo tiempo para evitar sobreuso
de procesador y memoria por concepto de tráfico de red desde PPP y Ethernet.
17
Dado que en PPP se utilizan 8 bits, mientras que los overlays del sistema utilizan 7 bits, el
puerto del sistema debería utilizar siempre 8 bits para satisfacer los requerimientos del
protocolo PPP. Debido a que el sistema siempre coloca el bit más significativo en alto (el
octavo bit en 1) las terminales receptoras deben configurarse para que apliquen una máscara
cuando van a comunicarse con overlays del sistema. De esta forma se ignora el octavo bit,
para evitar visualizar caracteres corruptos en la pantalla cuando se acceda a overlays del
sistema.
El protocolo PPP está diseñado para trabajar en comunicaciones “full dúplex”. La
velocidad de transmisión está limitada por el puerto SDI. La información se transmite con 8
bits, un bit de parada, ninguna paridad y modo de transmisión DTE, en una interface RS232C estándar.
2.1.3 Alarmas y mensajes del sistema
Para la mayoría de opciones del sistema, la CPU envía sólo un código cuando se envía
un mensaje. Para interpretar ese código y saber cuáles acciones son requeridas hay que
consultarlo en un documento denominado System Messages. Las opciones 51C, 61C, 81 y
81C dan aparte del código un texto explicativo y las acciones requeridas para algunos
mensajes.
A través de una terminal se pueden ingresar comandos para indicarle al sistema que
realice tareas específicas. El sistema ejecuta las tareas y envía mensajes de regreso a la
terminal, indicando el estado o errores. Los mensajes del sistema identifican fallas en el
equipo.
Los mensajes son códigos que tienen un nemónico seguido de un número. El nemónico
está asociado al tipo de falla y el número identifica al mensaje específico. Así, por ejemplo
el nemónico PWR identifica a una falla en la alimentación o temperatura, mientras que
18
PWR0014 se refiere específicamente que el monitor del sistema no ha podido completar una
autoevaluación. Un caso de los mensajes que incorporan descripción y acciones requeridas
puede ser “CCED200 CPU test failed Check the CP card”.
El monitor del sistema supervisa la temperatura, el estado del sistema de enfriamiento y
el voltaje de alimentación de cada módulo, así como el estado del CPU y el generador de
timbrado. En sistemas grandes pueden haber varios monitores de sistema. En este caso uno
de ellos actúa como máster o principal y los demás como esclavos. El monitor máster
entonces pregunta el estado a cada esclavo y manda el informe al CPU, que se comunica
únicamente con el monitor principal. Los mensajes generados por el monitor del sistema
tienen el nemónico PWR.
El Monitor de Errores es un programa residente que continuamente rastrea el
procesamiento de llamadas. Se generará un mensaje de sistema si el programa detecta
información de procesamiento de llamadas inválida o mal formateada. Los mensajes de
sistema generados por este programa van precedidos por el nemónico ERR, que usualmente
indica fallas de hardware, o el nemónico BUG, que generalmente indica problemas de
software.
En el proceso de inicialización se ejecuta un programa que momentáneamente
interrumpe el procesamiento de llamadas para limpiar fallas del CPU. Luego se rehabilita el
procesamiento de llamadas y se generan mensajes con el nemónico INI que indican el estado
del sistema.
El programa Overload Monitor monitorea continuamente el volumen de mensajes de
sistema. Si observa que alguna tarjeta de línea o trocal está generando muchos mensajes de
error, el programa deshabilita la tarjeta y genera mensajes con el nemónico OVD.
Hay en total más de 120 nemónicos para mensajes del sistema. La cantidad de errores
específicos con cada uno de los nemónicos varía mucho, ya que algunos tienen menos de 20
19
y otros más de 1000 mensajes específicos asociados. En el anexo 1 se enumeran todos los
nemónicos con su significado.
Existe la posibilidad de guardar un número limitado de ciertos tipos de mensajes de
sistema en un archivo histórico. Este archivo puede ser revisado cada vez que se desee y
puede escogerse los tipos de mensajes que se guardarán, de una lista de opciones. Si el
archivo está lleno y llega un nuevo mensaje, se eliminará el mensaje más viejo para guardar el
nuevo mensaje. En este caso, cuando se revise el archivo se desplegará el mensaje file
overflow, para advertir que se ha reemplazado información.
Las alarmas del sistema se basan en varios monitores de fallas e indicadores. La categoría de
la alarma -mayor, menor o remota- indica la severidad de la falla. Una alarma mayor requiere
una acción inmediata por parte de un técnico. Una alarma menor requiere acción por un
técnico, pero no necesariamente inmediata. Una alarma remota podría requerir atención por
el técnico.
Una alarma mayor indica una falla que interfiere seriamente con el proceso de llamadas.
Las siguientes fallas son causa de una alarma mayor:
•Falla
del CPU o bus de control.
•Falla en
•Falla
el disco del sistema cuando se intentaba cargarlo.
de la fuente de alimentación (si no hay respaldo de baterías o UPS).
•Exceso
de temperatura.
Cuando se presenta una alarma mayor se prende un LED rojo ubicado en la parte
superior de la columna afectada. Además se envía una indicación a todas las mesas de
operadoras. Por último, si la central está equipada con un PFTU, este conmuta y entonces
los teléfonos analógicos designados quedan conectados directamente a las troncales.
Una alarma menor indica que el sistema ha encontrado una falla de hardware o software
que requiere atención. Las siguientes fallas son causa de alarmas menores:
•Falla en
circuitos de conferencia.
20
•Falla en
el DTR.
•Falla en
la memoria.
•Más
de una falla en diferentes tarjetas de líneas o troncales.
•Falla
de red.
•Falla
de señalización de equipo periférico.
•Falla en
la interfaz de datos serial (SDI).
•Falla en
el TDS.
•Falla en
la identificación automática de marcación saliente.
Una alarma menor envía una indicación a las mesas de operadoras de los grupos
afectados por la falla. Esta indicación es opcional, puede ser deshabilitada.
Una alarma remota es una extensión opcional de una alarma mayor a otro lugar, como un
centro de control o centro de prueba, o un indicador como una luz o una campana. Cuando
se da una alarma mayor, la Meridian 1 cierra el contacto de un relé de 30Vdc y 2A.
Las alarmas del sistema también pueden enviar mensajes de la forma ABCDxxxx, donde
ABCD es el nemónico y xxxx es el código del mensaje de tres o cuatro dígitos. Hay alarmas
producidas por el sistema automáticamente(alarmas del sistema) y alarmas producidas
cuando un usuario interactúa con el equipo (alarmas de overlay).
Es posible filtrar las alarmas para recibir en una terminal solo cierto tipo de mensajes.
Por ejemplo, el usuario puede configurar una terminal para que reciba sólo los mensajes que
requieren atención. Esto se realiza por medio de una lista de alarmas y una lista de
excepciones. Aquellos mensajes que se encuentren en la lista de alarmas pero no en la de
excepciones serán enviados a la terminal. Por ejemplo, si se agrega PWR++++ a la lista de
alarmas, y PWR0000 a la lista de excepciones, entonces todos los mensajes PWR excepto el
PWR0000 se enviarán a la terminal. Sólo se pueden filtrar alarmas del sistema, en el anexo 1
se muestra cuáles mensajes pueden ser filtrados. Mensajes de tráfico y alarmas de overlay
21
no pueden ser filtradas. Puede definirse 50 campos en la lista de alarmas y 50 en la lista de
excepciones.
El filtro de alarmas permite dar a las alarmas un grado de severidad, de cuatro posibles:
ninguno, menor, mayor y crítica. Es posible establecer un número de repeticiones que debe
darse en 24 horas una alarma mayor para ser considerada como crítica. También se puede
establecer el número de veces que debe ocurrir un error en 24 para que sea suprimido,
evitando así mensajes redundantes.
A continuación se muestra el formato de los mensajes filtrados. La segunda y tercera
línea son opcionales.
<severidad> <id> <fecha> <hora> <no sec> <evento> <numero de secuencia>
Operator data:<mens op>
Expert data:<mens exp>
Donde
<severidad>
es la severidad de la alarma: ninguna, menor, mayor o crítica. Esta se
expresa por medio de asteriscos, donde *** equivale a critica, ** a
mayor, * a menor y sin asteriscos representa severidad ninguna.
<id>
es un identificador del error, hasta 10 caracteres, tal como BUG3001
<fecha>
Fecha de ocurrencia en formato DD/MM/AA
<hora>
Hora de ocurrencia en formato HH:MM:SS
<no sec>
número de secuencia de este reporte (5 dígitos).
<mens op>
un campo de 30 caracteres para ayudar a determinar cómo solucionar
la falla.
<mens exp>
un campo de 30 caracteres para uso de un experto para encontrar
fallas de programación.
22
Un ejemplo de alarma siguiendo el formato anterior es el siguiente:
*** BUG015 15/12/95 12:05:45 00345
EXPDATA: 04BEF0FC 05500FBA 05500EE2 05500EC6 05500EAA
BUG015 + 05500E72 + 05500E56 + 0550D96 + 055053A + 04D84E02 +
04D83CFC
2.2 Transmisión de datos en forma serial
El puerto serie es un dispositivo de entrada/salida muy utilizado para comunicar
equipos como enrutadores, centrales, UPS, etc con computadores. Generalmente consta de
un conector de 9 pines, de los cuales uno se usa para transmitir datos, otro para recibir y el
resto para control.
Figura 2.4: Conector DB9 típico
23
Tabla2.2: Designación de pines para un conector DB9 RS-232.
Pin
Descripción
Pin
Descripción
1
DCD- Data Carrier Detect
6
DSR-Data Set Ready
2
RXD- Received Data
7
RTS- Request To Send
3
TXD- Transmitted Data
8
CTS- Clear To Send
4
DTR- Data Terminal Ready
9
Ring Detect
5
GND- Logic Ground
Cuando la comunicación por el puerto serie se realiza en forma asíncrona, debe seguirse
cierto orden para que la computadora entienda dónde termina un dato y dónde empieza el
siguiente. El pin de transmisión está normalmente en 1. Cuando va a enviarse un dato, éste
debe ir precedido por un bit de inicio, que pone la línea en 0. A continuación se transmiten
todos los bits del dato (generalmente 8) y por último uno o más bits de parada, que indican
el final del dato. Opcionalmente se transmite también un bit de paridad. Los datos pueden
ser enviados o recibidos en cualquier momento, a esto se debe el nombre de asíncrono.
La cantidad de bits que forman un dato, los bits de parada y los bits de paridad son
parámetros de transmisión usualmente configurables. Para referirse a una transmisión de 8
bits de datos, un bit de parada y ninguna paridad, se escribe 8N1. Otro parámetro
importante que se debe configurar es la velocidad de la transmisión (o el baudaje) expresada
en bits por segundo. Es necesario que tanto el emisor como el receptor de un sistema de
transmisión serial tengan los mismos valores en los parámetros anteriores, para que la
comunicación pueda ser establecida correctamente.
Como parte importante en el proceso de enviar y recibir bits, hay un mecanismo de
control de flujo, encargado precisamente de regular el flujo de datos entre las dos interfaces
seriales. Existen dos sistemas de control de flujo. El primero de ellos es el control por
24
software, el cual utiliza las mismas líneas de transmisión y recepción de datos para enviar
los bits de inicio o parada. Cuando se utilizan caracteres especiales para enviar el bit de
inicio, se denomina XON, mientras en el caso del bit de parada, se llama XOFF. Los
caracteres especiales utilizados por XON y XOFF están definidos en el código ASCII, lo
que los hace útiles para transferencia de información textual. Sin embargo, al utilizar la
misma línea de transmisión, el control por software introduce un retardo en la velocidad real
de transmisión. El segundo sistema es el control por hardware, el cual utiliza más bien las
señales de control CTS y RTS del RS-232 para indicar cuándo un dispositivo está listo para
enviar o recibir más información.
La mayoría de la electrónica del puerto serie se encuentra en un chip llamado UART
(Universal Asyncronous Receiver/Transmiter). Este chip tiene un par de buffers (uno de
transmisión y otro de recepción) de 16 bytes cada uno. Además en la memoria principal hay
otro par de buffers de mayor tamaño, por ejemplo 8Kbytes.
Programa
de
Buffer en la
Buffer en la
<------------->memoria principal <--------------->UART <-------------> línea serial.
aplicación
8K bytes
16-bytes
Figura 2.5 Buffers presentes en la transmisión serial.
Una vez que un byte está en el buffer de la UART, éste será enviado, pero su flujo se
controla por el sistema de control, sea por hardware o por software. Si el control de flujo
detiene la transmisión y el programa envía n nuevos datos, éstos quedan en el buffer de la
memoria principal, hasta que el control de flujo acepte nuevos datos.
25
En los sistemas basados en Unix, como es el caso de Linux, una forma de acceder al
puerto serie es mediante su fichero descriptor /dev/ttyS0, el cual debe abrirse con una
llamada a una función como open().
Como el archivo /dev/ttyS0 puede tener permisos restringidos de lectura o escritura, el
programa encargado de abrir el puerto debe ser ejecutado por el superusuario, o bien,
cambiar los permisos del archivo o hacer que el programa corra como propietario del archivo
(no recomendable por cuestiones de seguridad).
2.3 Transmisión de datos por Internet
2.3.1 Definición red
Una red es un sistema de comunicación entre computadoras, incluye tanto el soporte
físico que abarca cableado y tarjetas de las computadoras, así como el conjunto de
programas que forman el sistema operativo de red.
Existen varias topologías para realizar una red, entre las que se encuentran la topología
bus, estrella y anillo. Además, de acuerdo con la relación entre los miembros de una red, ésta
se puede clasificar en dos grupos: redes con servidor y redes entre pares.
Otra clasificación se hace con base en la distancia que cubre la red. Así surgen otros dos
grupos: las redes de área local (LAN) y las redes de área extensa (WAN).
A su vez existen diferentes tecnologías de red, entre las que se encuentran Ethernet, redes
ATM,
redes Token Ring y otras. Algunas de estas tecnologías están enfocadas a la
conexión entre computadores, mientras que otras hacia la conmutación de paquetes.
El estudio detallado de las características de cada tecnología queda fuera de los objetivos
de este trabajo, sin embargo se incluye un vistazo rápido de la tecnología Ethernet, para
utilizarla como referencia.
26
2.3.2 Tecnología Ethernet
Ethernet es una popular tecnología LAN de conmutación de paquetes, utilizada
actualmente por muchas compañías medianas y grandes. Esta tecnología fue inventada por
Xerox, a principios de los años setenta. El diseño original utilizaba un cable coaxial. Sin
embargo, varios de los dispositivos originales presentaban características indeseables. Los
avances de la tecnología hicieron posible la construcción de redes Ethernet con cables de
cobre convencionales (par trenzado).
Conocido con el nombre de 10Base-T, el esquema de cableado de par trenzado conecta
cada computadora con un hub (concentrador) Ethernet. La conexión entre una computadora
y el hub no debe ser mayor a 100m.
Cuando una computadora envía un paquete, el hub lo transmite a todas las demás
computadoras. Por eso se dice que Ethernet es un bus de difusión. Además, Ethernet es un
sistema entre pares, o punto a punto, ya que no existe un servidor o autoridad central para
garantizar el acceso. Los paquetes se transmiten y no se proporciona información de si el
paquete se ha recibido o no.
Debido a su topología de bus, cada tarjeta de red debe monitorear el canal mientras está
transmitiendo, para saber si hay alguna señal exterior que interfiera con su transmisión. Esto
se conoce como detección de colisiones. Si se detecta una colisión, el emisor aborta la
transmisión e intenta retransmitir después de cierto tiempo, obtenido por un procedimiento
de retroceso exponencial, para evitar que las transmisiones de dos emisores estén
continuamente colisionando.
Como se mencionó anteriormente, cada paquete es difundido por el hub hacia todas las
demás computadoras conectadas; sin embargo, generalmente se desea que el paquete sea
recibido por una computara en particular.
27
Para lograr lo anterior, las redes Ethernet definen un sistema de direccionamiento de 48
bits. A cada computadora conectada se le asigna un número único de 48 bits (6 octetos).
Este número se conoce como dirección Ethernet, y es un valor dado por el fabricante del
hardware. De esta manera, no existen dos unidades de hardware de interfaz con la misma
dirección Ethernet.
Cada paquete o trama de Ethernet consta de un encabezado donde se coloca la dirección
de destino, la dirección fuente y otros datos de control, como se muestra en la siguiente
figura:
Preámbul
o
8
octetos
Dirección
destino
6
octetos
Dirección Datos de
la trama
fuente
6
octetos
Área de
datos
64-1500
octetos
2
octetos
CRC
4
octetos
Figura2.6: Representación de una trama de Ethernet.
El encabezado de la trama incluye el preámbulo, las direcciones fuente y destino (estas
son las direcciones Ethernet, llamadas también MAC address) y el tipo de datos que se
están transfiriendo. El preámbulo consiste en un conjunto de bits que alternan unos y ceros
para ayudar a la sincronización de los nodos de recepción. Además, cada trama tiene otro
conjunto de bits para verificación por redundancia cíclica (CRC) que ayuda a la interfaz a
detectar los errores de transmisión.
2.3.3 Definición TCP / IP
28
Como se ha visto, las redes pueden proceder de una variedad de fabricantes y es
probable que tenga diferencias tanto en hardware como en software. Así mismo, puede ser
de diferente tecnología. Para posibilitar la comunicación entre éstas es necesario un conjunto
de reglas formales para su interacción. A estas reglas se les denominan protocolos.
Se han desarrollado diferentes familias de protocolos para comunicación por red de
datos para los sistemas UNIX. El más ampliamente utilizado es el Internet Protocol Suite,
comúnmente conocido como TCP / IP.
Es un protocolo que proporciona transmisión fiable de paquetes de datos sobre redes.
El nombre TCP / IP Proviene de dos protocolos importantes de la familia, el Transmission
Control Protocol (TCP) y el Internet Protocol (IP). Todos juntos llegan a ser más de 100
protocolos diferentes definidos en este conjunto.
El TCP / IP es la base del Internet que sirve para enlazar computadoras que utilizan
diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras
centrales sobre redes de área local y área extensa. TCP / IP fue desarrollado y demostrado
por primera vez en 1972 por el departamento de defensa de los Estados Unidos,
ejecutándolo en el ARPANET, una red de área extensa del departamento de defensa.
2.3.4 Modelo de referencia iso de 7 capas
Existen dos modelos dominantes sobre la estratificación por capas de protocolo. La
primera, basada en el trabajo realizado por la International Organization for Standardization
(Organización para la Estandarización o ISO, por sus siglas en inglés ), conocida como
Referencia Model of Open System Interconnection Modelo de referencia de interconexión
de sistemas abiertos ) de ISO, denominada frecuentemente modelo ISO.
El modelo ISO
contiene 7 capas conceptuales organizadas como se muestra a continuación:
29
CAPA
FUNCION
1
Aplicación
2
Presentación
3
Sesión
4
Transporte
5
Red
6
Enlace de datos (Interfaz de Hardware)
7
Conexión de Hardware Físico
Figura 2.7 Modelo por capas ISO.
El modelo ISO, elaborado para describir protocolos para una sola red, no contiene un
nivel especifico para el ruteo en el enlace de redes, como sucede con el protocolo TCP/IP.
Capas:
•Conexión de hardware físico: proporciona los medios mecánicos, eléctricos, funcionales y
de procedimiento para mantener y desactivar las conexiones físicas para la transmisión de
bits entre entidades de enlace de datos. Así, en este nivel, la normativa establece parámetros
de tensión, características de los cables, etc.
•Enlace de datos: El objetivo de la capa de enlace es facilitar los medios funcionales y de
procedimientos para establecer, mantener y liberar conexiones de enlace de datos. Sus
funciones básicas en resumen son:
30
oSincronización y entramado
oEstablecimiento y desconexión del enlace
oControl de flujo
oDetección y recuperación de errores.
•Red: El objetivo de esta capa es el de proporcionar los medios para establecer, mantener y
liberar la conexión, a través de una red donde existe una malla compuesta de enlaces y
nodos. Es el responsable de las funciones de conmutación y encaminamiento de la
información.
•Transporte: Su función principal esta en controlar que la información transmitida entre dos
computadoras llegue al destinatario tal y como le fue enviada.
•Sesión: Se encarga de sincronizar y organizar el intercambio de información entre distintos
usuarios.
•Presentación: Da una normativa de cómo se tiene que realizar la presentación de los datos
para obtener compatibilidad entre los usuarios (códigos de caracteres usados, etc.)
•Aplicación: Su función es la de actuar como interface con el usuario y con el resto de capas,
permitiendo al usuario introducir opciones.
2.3.5 Dispositivos para el interfuncionamiento de INTERNET
31
En forma general, los equipos utilizados para la interconexión de redes son (en la figura se
muestra como actúan sobre distintos niveles del modelo OSI):
7 Aplicación
7 Aplicación
6 Presentación
6 Presentación
5 Sesión
4 Transporte
5 Sesión
Gateways
4 Transporte
3 Red
Routers
3 Red
2 Enlace
Bridges
2 Enlace
1 Físico
Repeaters
1 Físico
Figura 2.8: Dispositivos para el funcionamiento de Internet.
•Repetidores o “Repeaters”: Son el dispositivo más elemental de la serie y, como su nombre
indica, se limitan simplemente a regenerar la señal, sin cambiar su físico de transmisión
empleado: cable coaxial, de pares, fibra óptica, etc.
•Puentes o “Bridges”: Sirven para enlazar dos o más LANs que empleen igual protocolo de
enlace. No realizan control de flujo, ignorando protocolos de nivel superior, por lo que se
comportan de forma transparente respecto a estos.
•Encaminadotes o “Routers”: Operan de manera similar a los puentes, con la particularidad
de que lo hacen en la capa de red de OSI, que incluye una dirección de red y una de
32
dispositivo; ello proporciona innumerables ventajas, ya que permite la interoperatividad
entre redes diferentes, como pueden ser CDMA/CD y una Token Ring, y permite dividir
una red en varias subredes, eligiendo el mejor camino para enviar un paquete sin la necesidad
de mantener extensas tablas que contengan la dirección de todos y cada uno de los
dispositivos.
•Pasarelas o “Gateways”: Son dispositivos especializados en proporcionar conectividad,
desde el acceso, entre entornos con diferentes protocolos, actuado como traductores.
2.3.6 El X.25 y su relación con el modelo ISO
Aun cuando fue diseñado para proporcionar un modelo conceptual y no una guía de
implementación, el esquema de estratificación por capas de ISO ha sido la base para la
implementación de varios protocolos. Entre los protocolos comúnmente asociados con el
modelo ISO, el conjunto de protocolos conocido como X.25 es probablemente el mejor
conocido y el más ampliamente utilizado. X.25 fue establecido como una recomendación de
la Telecommunications Section de la International Telecommunications Union (ITU-TS),
una organización internacional que recomienda estándares para los servicios telefónicos
internacionales. X.25 ha sido adoptado para las redes públicas de datos y es especialmente
popular en Europa. Consideraremos a X.25 para ayudar a explicar la estratificación por
capas de ISO.
Dentro de la perspectiva de X.25, una red opera en gran parte como un sistema
telefónico. Una red X.25 se asume como si estuviera formada por complejos conmutadores
de paquetes que tienen la capacidad necesaria para el ruteo de paquetes. Los anfitriones no
están comunicados de manera directa a los cables de comunicación de la red. En lugar de
ello, cada anfitrión se comunica con uno de los conmutadores de paquetes por medio de una
33
línea de comunicación serial. En cierto sentido la comunicación entre un anfitrión y un
conmutador de paquetes X.25 es una red miniatura que consiste en un enlace serial. El
anfitrión puede seguir un complicado procedimiento para transferir paquetes hacia la red.
2.3.7 El modelo de estratificación por capas de TCP/IP de Internet
El segundo modelo mayor de estratificación por capas no se origina de un comité de
estándares, sino que proviene de las investigaciones que se realizan respecto al conjunto de
protocolos de TCP/IP. Con un poco de esfuerzo, el modelo ISO puede ampliarse y
describir el esquema de estratificación por capas del TCP/IP, pero
los presupuestos
subyacentes son lo suficientemente distintos para distinguirlos como dos diferentes.
En términos generales, el software TCP/IP está organizado en cuatro capas conceptuales
que se construyen sobre una quinta capa de hardware. El siguiente esquema muestra las
capas conceptuales así como la forma en que los datos pasan entre ellas.
34
CAPAS CONCEPTUALES
PASO DE OBJETOS ENTR E CAPAS
APLICACIÓN
FLUJOS O MENSAJES
TRANSPORTE
PAQUETES DE PROTOCOLOS
DE TRANSPORTE
INTERNET
INTERFAZ DE RED
DATAGRAMA IP
HARDWARE
TRAMAS ESPECIFICAS DE RED
Figura 2.9 Capas conceptuales del TCP/IP
•Capa de aplicación. Es el nivel mas alto, los usuarios llaman a una aplicación que acceda
servicios disponibles a través de la red de redes TCP/IP. Una aplicación interactúa con uno
de los protocolos de nivel de transporte para enviar o recibir datos. Cada programa de
aplicación selecciona el tipo de transporte necesario, el cual puede ser una secuencia de
mensajes individuales o un flujo continuo de octetos. El programa de aplicación pasa los
datos en la forma requerida hacia el nivel de transporte para su entrega.
•Capa de transporte. La principal tarea de la capa de transporte es proporcionar la
comunicación entre un programa de aplicación y otro. Este tipo de comunicación se conoce
frecuentemente como comunicación punto a punto. La capa de transporte regula el flujo de
información. Puede también proporcionar un transporte confiable, asegurando que los datos
lleguen sin errores y en secuencia. Para hacer esto, el software de protocolo de transporte
tiene el lado de recepción enviando acuses de recibo de retorno y la parte de envío
retransmitiendo los paquetes perdidos. El software de transporte divide el flujo de datos
que se está enviando en pequeños fragmentos (por lo general conocidos como paquetes) y
pasa cada paquete, con una dirección de destino, hacia la siguiente capa de transmisión. Aun
35
cuando en el esquema anterior se utiliza un solo bloque para representar la capa de
aplicación, una computadora de propósito general puede tener varios programas de
aplicación accesando la red de redes al mismo tiempo. La capa de transporte debe aceptar
datos desde varios programas de usuario y enviarlos a la capa del siguiente nivel. Para hacer
esto, se añade información adicional a cada paquete, incluyendo códigos que identifican qué
programa de aplicación
envía y qué programa debe recibir, así como una suma de
verificación para verificar que el paquete ha llegado intacto y utiliza el código de destino
para identificar el programa de aplicación en el que se debe entregar.
•Capa Internet. La capa Internet maneja la comunicación de una máquina a otra. Ésta acepta
una solicitud para enviar un paquete desde la capa de transporte, junto con una
identificación de la máquina, hacia la que se debe enviar el paquete. La capa Internet también
maneja la entrada de datagramas, verifica su validez y utiliza un algoritmo de ruteo para
decidir si el datagrama debe procesarse de manera local o debe ser transmitido. Para el caso
de los datagramas direccionados hacia la máquina local, el software de la capa de red de redes
borra el encabezado del datagrama y selecciona, de entre varios protocolos de transporte, un
protocolo con el que manejará el paquete. Por último, la capa Internet envía los mensajes
ICMP de error y control necesarios y maneja todos los mensajes ICMP entrantes.
•Capa de interfaz de red. El software TCP/IP de nivel inferior consta de una capa de
interfaz de red responsable de aceptar los datagramas IP y transmitirlos hacia una red
específica. Una interfaz de red puede consistir en un dispositivo controlador (por ejemplo,
cuando la red es una red de área local a la que las máquinas están conectadas directamente) o
un complejo subsistema que utiliza un protocolo de enlace de datos propios (por ejemplo,
cuando la red consiste de conmutadores de paquetes que se comunican con anfitriones
utilizando HDLC).
36
2.3.8 Estratificación por capas en un ambiente de Internet TCP/IP
Anfitrión A
Anfitrión B
Aplicación
Aplicación
Mensaje
idéntico
Transporte
Transporte
Paquete
idéntico
Ruteador
Internet
Internet
Internet
datagrama
idéntico
datagrama
idéntico
Interfaz de
Red
Interfaz de
Red
Interfaz de
Red
Red física 2
Red física 1
Figura 2.10 Estratificación por capas en una Internet con TCP
Como se muestra en la figura, la entrega del mensaje utiliza dos estructuras de red
separadas, una para la transmisión desde el anfitrión A hasta el ruteador R y otra del
ruteador R al anfitrión B. El siguiente principio de trabajo de estratificación de capas indica
que el marco entregado a R es idéntico al enviado por el anfitrión A. En contraste, las capas
de aplicación y transporte cumplen con la condición punto a punto y están diseñados de
modo que el software en la fuente se comunique con su par en el destino final. Así, el
principio de la estratificación por capas establece que el paquete recibido por la capa de
transporte en el destino final es idéntico al paquete enviado por la capa de transporte en la
fuente original.
37
Es fácil entender que, en las capas superiores, el principio de estratificación por capas
se aplica a través de la transferencia punto a punto y que en las capas inferiores se aplica en
una sola transferencia de máquina. No es tan fácil ver como el principio de estratificación de
capas se aplica a la estratificación Internet. Por un lado, se ha dicho que los anfitriones
conectados a una red de redes deben considerarse como una gran red virtual, con los
datagramas IP que hacen las veces de tramas de red. Desde este punto de vista, los
datagramas viajan desde una fuente original hacia un destino final y el principio de la
estratificación por capas garantiza que el destino final reciba exactamente el datagrama que
envío la fuente. Por otra parte, sabemos que el encabezado "datagram” contiene campos,
como "time to live", que cambia cada vez que el "datagram" pasa a través de un ruteador.
Así, el destino final no recibirá exactamente el mismo diagrama que envío la fuente.
Se debe concluir que, a pesar de que la mayor parte de los datagramas permanecen
intactos cuando pasan a través de una red de redes, el principio de estratificación por capas
solo se aplica a los datagramas que realizan transferencias de una sola máquina. Para ser
precisos, no debemos considerar que las capas de Internet proporcionan un servicio punto a
punto.
2.3.9 Estratificación por capas en presencia de una subestructura de red
Cuando un ruteador recibe un datagrama, este puede entregar el datagrama en su destino
o en la red local, o transferir el datagrama a través de una línea serial hacia otro ruteador. La
cuestión es la siguiente: "¿cómo se ajusta el protocolo utilizado en una línea serial con
respecto al esquema de estratificación por capas del TCP/IP?" La respuesta depende de
como considera el diseñador la interconexión con la línea serial.
38
Desde la perspectiva del IP, el conjunto de conexiones punto a punto entre ruteadores
puede funcionar como un conjunto de redes físicas independientes o funcionar
colectivamente como una sola red física. En el primer caso, cada enlace físico es tratado
exactamente como cualquier otra red en una red de redes. A esta se le asigna un numero
único de red (por lo general de clase C) y los dos anfitriones que comparten el enlace tiene
cada uno una dirección única IP asignada para su conexión. Los ruteadores se añaden a la
tabla de ruteo IP como lo harían para cualquier otra red. Un nuevo modulo de software se
añade en la capa de interfaz de red para controlar el nuevo enlace de hardware, pero no se
realizan cambios sustanciales en el esquema de estratificación por capas. La principal
desventaja del enfoque de redes independientes es la proliferación de números de redes (uno
por cada conexión entre dos maquinas), lo que ocasiona que las tablas de ruteo sean tan
grandes como sea necesario. Tanto la línea serial IP (Serial Line IP o SLIP) como el
protocolo punto a punto (Point to Point Protocol o PPP) tratan a cada enlace serial como
una red separada.
El segundo método para ajustar las conexiones punto a punto evita asignar múltiples
direcciones IP al cableado físico.
En lugar de ello, se tratan a todas las conexiones
colectivamente como una sola red independiente IP con su propio formato de trama,
esquema de direccionamiento de hardware y protocolos de enlace de datos. Los ruteadores
que emplean el segundo método necesitan solo un numero de red IP para todas las
conexiones punto a punto.
Usar el enfoque de una sola red significa extender el esquema de estratificación por
capas de protocolos para añadir una nueva capa de ruteo dentro de la red, entre la capa de
interfaz de red y los dispositivos de hardware. Para las máquinas con una sola conexión
punto a punto, una capa adicional parece innecesaria. La organización del software de la
capa Internet pasa hacia la interfaz de red todos los datagramas que deberá enviarse por
cualquier conexión punto a punto. La interfaz los pasa hacia él modulo de ruteo dentro de la
39
red que, además, debe distinguir entre varias conexiones físicas y rutear el datagrama a través
de la conexión correcta.
El programador que diseña software de ruteo dentro de la red determina exactamente
como selecciona el software un enlace físico. Por lo general, el algoritmo conduce a una tabla
de ruteo dentro de la red. La tabla de ruteo dentro de la red es análoga a una tabla de ruteo
de una red de redes en la que se especifica una transformación de la dirección de destino
hacia la ruta. La tabla contiene pares de enteros, (D, L), donde D es una dirección de
destino de un anfitrión y L especifica una de las líneas físicas utilizadas para llegar al
destino.
Las diferencias entre una tabla de ruteo de red de redes y una tabla de ruteo dentro de la
red son que esta ultima, es mucho más pequeña. Contiene solamente información de ruteo
para los anfitriones conectados directamente a la red punto a punto. La razón es simple: la
capa Internet realiza la transformación de una dirección de destino arbitraria hacia una ruta
de dirección especifica antes de pasar el datagrama hacia una interfaz de red. De esta
manera, la capa dentro de la red solo debe distinguir entre máquinas en una sola red unto a
punto.
2.3.10 Como funciona TCP/IP
Una red TCP/IP transfiere datos mediante el ensamblaje de bloques de datos en
paquetes, cada paquete comienza con una cabecera que contiene información de control; tal
como la dirección del destino, seguido de los datos. Cuando se envía un archivo por la red
TCP/IP, su contenido se envía utilizando una serie de paquetes diferentes. El Internet
protocol (IP), un protocolo de la capa de red, permite a las aplicaciones ejecutarse
transparentemente sobre redes interconectadas.
Cuando se utiliza IP, no es necesario
conocer que hardware se utiliza, por tanto ésta corre en una red de área local.
40
El Transmissión Control Protocol (TCP); un protocolo de la capa de transporte,
asegura que los datos sean entregados, que lo que se recibe, sea lo que se pretendía enviar y
que los paquetes que sean recibidos en el orden en que fueron enviados. TCP terminará una
conexión si ocurre un error que haga la transmisión fiable imposible.
Una abstracción que los protocolos de transporte del TCP/IP utilizan para ordenar,
asignar y distinguir conexiones son los puertos de protocolo. Los protocolos TCP/IP
identifican puertos mediante enteros pequeños positivos. Usualmente el sistema operativo
permite a un programa de aplicación especificar qué puerto desea utilizar. Algunos puertos
se reservan para servicios estándar (por ejemplo, el puerto 80 se utiliza como servidor de
páginas Web (http), mientras que el puerto 21 es para ftp, etc)
2.3.11 Administración TCP/IP
TCP/IP es una de las redes más comunes utilizadas para conectar computadoras con
sistema UNIX. Las utilidades de red TCP/IP forman parte de la versión 4, muchas
facilidades de red como un sistema UUCP, el sistema de correo, RFS y NFS, pueden utilizar
una red TCP/CP para comunicarse con otras máquinas.
Para que la red TCP/IP esté activa y funcionado será necesario:
•Obtener una dirección Internet.
•Instalar las utilidades Internet en el sistema
•Configurar la red para TCP/IP
•Configurar los guiones de arranque TCP/IP
•Identificar otras máquinas ante el sistema
•Configurar la base de datos del o y ente de STREAMS
•Comenzar a ejecutar TCP/IP.
41
2.3.12 ¿Qué es internet?
Internet es una red de computadoras que utiliza convenciones comunes a la hora de
nombrar y direccionar sistemas. Es una colecciona de redes independientes interconectadas;
no hay nadie que sea dueño o active Internet al completo.
Las computadoras que componen Internet trabajan en UNIX, el sistema operativo
Macintosh, Windows 95 y muchos otros. Utilizando TCP/IP y los protocolos veremos
dos servicios de red:
: Servicios de Internet a nivel de aplicación
: Servicios de Internet a nivel de red
2.3.13 Servicios de internet a nivel de aplicación:
Desde el punto de vista de un usuario, una red de redes TCP/IP aparece como un grupo
de programas de aplicación que utilizan la red para llevar a cabo tareas útiles de
comunicación. Utilizamos el término interoperabilidad para referirnos a la habilidad que
tienen diversos sistemas de computación para cooperar en la resolución de problemas
computacionales. Los programas de aplicación de Internet muestran un alto grado de
interoperabilidad.
La mayoría de usuarios que accesan a Internet lo hacen al correr
programas de aplicación sin entender la tecnología TCP/IP, la estructura de la red de redes
subyacente o incluso sin entender el camino que siguen los datos hacia su destino. Sólo los
programadores que crean los programas de aplicación de red necesitan ver a la red de redes
como una red, así como entender parte de la tecnología. Los servicios de aplicación de
Internet más populares y difundidos incluyen:
42
•Correo electrónico. El correo electrónico permite que un usuario componga memorandos y
los envíe a individuos o grupos. Otra parte de la aplicación de correo permite que un
usuario lea los memorandos que ha recibido. El correo electrónico ha sido tan exitoso que
muchos usuarios de Internet depende de él para su correspondencia normal de negocios.
Aunque existen muchos sistemas de correo electrónico, al utilizar TCP/IP se logra que la
entrega sea más confiable debido a que non se basa en compradoras intermedias para
distribuir los mensajes de correo. Un sistema de entrega de correo TCP/IP opera al hacer
que la máquina del transmisor contacte directamente la máquina del receptor. Por lo tanto,
el transmisor sabe que, una vez que el mensaje salga de su máquina local, se habrá recibido
de manera exitosa en el sitio de destino.
•Transferencia de archivos. Aunque los usuarios algunas veces transfieren archivos por
medio del correo electrónico, el correo está diseñado principalmente para mensajes cortos de
texto. Los protocolos TCP/IP incluyen un programa de aplicación conocido como FTP
(File Transfer Protocol) para transferencia de archivos, el cual permite que lo usuarios
envíen o reciban archivos arbitrariamente grandes de programas o de datos. Por ejemplo, al
utilizar el programa de transferencia de archivos, se puede copiar de una máquina a otra una
gran base de datos que contenga imágenes de satélite, un programa escrito en Pascal o C++,
o un diccionario del idioma inglés. El sistema proporciona una manera de verificar que los
usuarios cuenten con autorización o, incluso, de impedir el acceso. Como el correo, la
transferencia de archivos a través de una red de redes TCP/IP es confiable debido a que las
dos máquinas comprendidas se comunican de manera directa, sin tener que confiar en
máquinas intermedias para hacer copias del archivo a lo largo del camino.
•Acceso remoto.
El acceso remoto permite que un usuario que esté frente a una
computadora se conecte a una máquina remota y establezca una sesión interactiva. El
43
acceso remoto hace aparecer una ventana en la pantalla del usuario, la cual se conecta
directamente con la máquina remota al enviar cada golpe de tecla desde el teclado del usuario
a una máquina remota y muestra en la ventana del usuario cada carácter que la computadora
remota lo genere. Cuando termina la sesión de acceso remoto, la aplicación regresa al
usuario a su sistema local. Este aplicación se conoce como TELNET (Telecommunicating
Networks)
•Gopher. Es un servicio de búsqueda y recuperación de ficheros distribuidos por toda la red
que emplea una estructura jerárquica de menús. Es un servicio de información sobre los
recursos de la red en los que cada servidor se encarga de organizar su propia información,
siendo las referencias cruzadas entre ellos lo que permite que funcionen con un conjunto
único.
•Grupos de Noticias (News). Son grupos de discusión, abiertos o cerrados, sobre temas de
interés muy variado. Funciona a modo de los tablones de anuncios en los que cualquiera
puede dejar o leer mensajes. Una variante de este servicio es IRC (Internet Relay Chat) un
servicio que permite intercambiar mensajes por escrito en tiempo real.
•World Wide Web. WWW es uno de los servicios que experimenta un crecimiento mayor.
Fue desarrollado por CERN (Centro Europeo de Estudios Nucleares) y consiste en un
estándar (HTML/Hypertext Markup Language) para presentar y visualizar páginas
multimedia –texto, sonidos, imágenes, vídeos- que emplea hipertexto (documentos que
contienen enlaces o vínculos con otros documentos), siendo muy fácil de utilizar. El lenguaje
HTML no especifica elementos tipográficos exactos, sino el papel del texto dentro del
documento, lo que permite cualquier plataforma. Una página HTML se puede crear con un
simple editor de texto y programa gráfico estándar, no siendo necesaria ninguna herramienta
44
de programación. Para transmitir información escrita en HTML se utiliza el protocolo
HTTP (Hiper Text Transfer Protocol), el cual está definido como parte del TCP/IP.
2.3.14 Servicios de internet a nivel de red
Un programador que crea programas de aplicación que utilizan protocolos TCP/IP tiene
una visión totalmente diferente de una red de redes, con respecto a la visión que tiene un
usuario que únicamente ejecuta aplicaciones como el correo electrónico. En el nivel de red,
una red de redes proporciona dos grandes tipos de servicios que todos los programas de
aplicación utilizan. Aunque no es importante en este momento entender los detalles de
estos servicios, no se deben omitir del panorama general del TCP/IP:
•Servicio sin conexión de entrega de paquetes (UDP). La entrega sin conexión es una
abstracción del servicio que la mayoría de las redes de conmutación de paquetes ofrece.
Simplemente significa que una red de redes TCP/IP rutea mensajes pequeños de una
máquina a otra, basándose en la información de dirección que contiene cada mensaje.
Debido a que el servicio sin conexión rutea cada paquete por separado, no garantiza una
entrega confiable y en orden. Como por lo general se introduce directamente en el hardware
subyacente, el servicio sin conexión es muy eficiente.
•Servicio de transporte de flujo confiable (TCP). La mayor parte de las aplicaciones
necesitan mucho más que sólo la entrega de paquetes, debido a que requieren que el software
de comunicaciones se recupere de manera automática de los errores de transmisión, paquetes
perdidos o fallas de conmutadores intermedios a lo largo del camino entre el transmisor y el
receptor. El servicio de transporte confiable resuelve dichos problemas. Permite que una
aplicación en una computadora establezca una “conexión” con una aplicación en otra
45
computadora, para después enviar un gran volumen de datos a través de la conexión como si
fuera perramente y directa del hardware.
Muchas redes proporcionan servicios básicos similares a los servicios TCP/IP,
pero
existen unas características principales que los distingue de los otros servicios:
•Independencia de la tecnología de red. Ya que el TCP/IP está basado en una tecnología
convencional de conmutación de paquetes, es independiente de cualquier marca de hardware
en particular. La Internet global incluye una variedad de tecnologías de red que van de redes
diseñadas para operar dentro de un solo edificio a las diseñadas para abarcar grandes
distancias. Los protocolos TCP/IP definen la unidad de transmisión de datos, llamada
datagrama, y especifican cómo transmitir los datagramas en una red en particular.
•Interconexión universal. Una red de redes TCP/IP permite que se comunique cualquier par
de computadoras conectadas a ella.
Cada computadora tiene asignada una dirección
reconocida de manera universal dentro de la red de redes. Cada datagrama lleva en su
interior las direcciones de destino para tomar decisiones de ruteo.
•Acuses de recibo punto-a-punto.
Los protocolos TCP/IP
de una red de redes
proporcionan acuses de recibo entre la fuente y el último destino en vez de proporcionarlos
entre máquinas sucesivas a lo largo del camino, aún cuando las dos máquinas no estén
conectadas a la misma red física.
•Estándares de protocolo de aplicación.
Además de los servicios básicos de nivel de
transporte (como las conexiones de flujo confiable), los protocolos TCP/IP incluyen
estándares para muchas aplicaciones comunes, incluyendo correo electrónico, transferencia
46
de archivos y acceso remoto. Por lo tanto, cuando se diseñan programas de aplicación que
utilizan el TCP/IP, los programadores a menudo se encuentran con que el software ya
existente proporciona los servicios de comunicación que necesitan.
2.3.15 Protocolos para la gestión de redes
Dado que la tendencia natural de una red cualquiera es a crecer, conforme se añaden
nuevas aplicaciones y más y más usuarios hacen uso de la misma, los sistemas de gestión
empleados han de ser lo suficientemente flexibles para poder soportar los nuevos elementos
que se van añadiendo. Con la idea de presentar una solución única, para cualquier tipo de red
se diseño el protocolo SNMP (Simple Network Managment Protocol).
Para el protocolo SNMP la red constituye un conjunto de elementos básicos –
Administradores o Gestores- ubicados en el/los equipo/s de gestión de red y Agentes
(elementos pasivos ubicados en los nodos –host, routers, multiplexores, módems, etc. A ser
gestionados-), siendo los segundos los que envían información a los primeros, relativa a los
elementos gestionados, bien al ser interrogados o de manera secuencial.
2.4 La interfaz Socket
Para que los programas de aplicación puedan hacer uso de los diferentes protocolos
debe existir entre ambos una interfaz. La arquitectura de la interfaz no está estandarizada:
existen diferencias entre un sistema operativo y otro. Sin embargo, los sockets son una
interfaz que es soportada en diferentes ambientes, por lo que es útil tomarla como base.
Originalmente los sockets fueron desarrollados para el sistema UNIX, pero actualmente
existen variantes como la interfaz Winsock, que proporciona la funcionalidad socket para
47
Micosoft Windows. Los sockets también están disponibles en las distintas distribuciones
de Linux, así como en el sistema MacOS.1
Además, los sockets son soportados por lenguajes de programación de alto nivel
comunes como C/C++, Java y Perl, entre otros.
Los sockets son mecanismos de comunicación entre procesos que permiten que un
proceso intercambie información con otro, incluso estando estos procesos en distintas
máquinas. Como proceso debe entenderse cualquier programa de aplicación que se ejecuta a
nivel de usuario.
Antes de poder describir más detalladamente los sockets se debe introducir el paradigma
de E/S que sigue el sistema UNIX. En este sistema operativo, los procesos de entrada/salida
siguen un modelo open-read-write-close (abrir-leer-escribir-cerrar). De esta forma, antes de
que un proceso pueda realizar operaciones de E/S debe llamar a una función open para
especificar el archivo o dispositivo que se va a usar. La llamada a open devuelve un entero
descriptor de archivo. (En UNIX, los dispositivos son transformados en el archivo de
espacio de nombre se sistema. Las operaciones de E/S entre archivos y dispositivos no
tienen diferencias, en la mayoría de los casos. Por ejemplo, una unidad de disco compacto
podría estar representada por un archivo especial denominado /dev/cdrom).
Luego de que se ha abierto un objeto, se realizan las operaciones de lectura y escritura
necesarias por medio de funciones read y write, respectivamente. Al finalizar las
operaciones de transferencia, el proceso de usuario llama a close para informar al sistema
operativo que se ha terminado de usar el objeto.
En un principio, los diseñadores de UNIX agruparon las operaciones de E/S de red bajo
el paradigma anterior, utilizando el archivo especial /dev/tcp. Sin embargo, los protocolos de
red eran más complejos que los dispositivos normales de E/S. Además se deseaba que los
servidores fueran capaces de esperar conexiones pasivamente, así como la posibilidad de
1En esta sección se hace referencia a la interfaz Socket bajo el sistema BSD de UNIX.
48
mandar la dirección de destino con cada datagrama y no destinos enlazados en el momento
en que se llama a open. Estas razones impulsaron a los diseñadores a abandonar el modelo
de E/S descrito previamente, y los llevó a adoptar a los sockets como una generalización del
mecanismo de acceso a archivos de UNIX, que permiten adoptar varios protocolos.
Al igual que con el acceso a archivos, los programas de aplicación requieren que el
sistema operativo cree un socket cuando lo necesite. El sistema devuelve un entero,
denominado descriptor, que utiliza el programa de aplicación para hacer referencia al socket.
La diferencia entre descriptores de archivos y descriptores de socket es que los primeros
hacen referencia siempre a un archivo o dispositivo específico cuando la aplicación llama a
open, mientras que se pueden crear sockets si enlazarlos a direcciones de destino
específicas.
La aplicación puede elegir entre abastecer una dirección de destino cada vez que se
utiliza el socket (como en el caso de envío de datagramas), o bien, enlazar la dirección de
destino a un socket (como en el caso de una conexión TCP).
Los sockets conservan semejanzas con las operaciones de E/S con descriptores de
archivos. De esta forma, es posible realizar operaciones semejantes a read y write. Así, un
proceso puede escribir en un socket, lo cual implica mandar un flujo de datos a través de la
conexión, mientras que el otro proceso puede leer del socket para recibir los datos.
El proceso de comunicación con sockets está basado en la filosofía Cliente-Servidor.
Existe un proceso servidor, que crea un socket cuyo nombre lo conocerá el proceso cliente.
Ambos procesos podrán entonces comunicarse en forma bidireccional por medio de la
conexión con dicho socket nombrado.
Los pasos a seguir para entablar la comunicación son básicamente los siguientes:
1º) El proceso servidor crea un socket con nombre y espera la conexión.
2º) El proceso cliente crea un socket sin nombre.
3º) El proceso cliente realiza una petición de conexión al socket servidor.
49
4º) El cliente realiza la conexión a través de su socket mientras el proceso servidor
mantiene el socket servidor original con nombre.
Es muy común que cuando se establece la comunicación, el servidor lance un proceso
hijo para que se encargue de la transferencia de datos, mientras que el padre continúa
esperando conexiones. Cuando un proceso termina de utilizar un socket, éste llama a una
función close para cerrar el socket.
Los sockets se distinguen por dos características fundamentales: el tipo y el dominio.
En la creación del socket se definen estas características para darle a la conexión la
funcionalidad deseada, pasándolas como parámetros de la función que abre el socket: int
socket (dominio, tipo, protocolo). El resultado de esta llamada es el descriptor del socket
recién creado.
El tipo del socket se refiere a la naturaleza del mismo, el tipo de comunicación que puede
brindar. Los tipos disponibles son los siguientes:
* Tipo SOCK_DGRAM: sockets para comunicaciones en modo no conectado, con
envío de datagramas de tamaño limitado. Se basa sobre el protocolo UDP.
* Tipo SOCK_STREAM:
para comunicaciones fiables en modo conectado, de dos
vías y con tamaño variable de los mensajes de datos. Utiliza el protocolo TCP.
* Tipo SOCK_RAW:
permite el acceso a protocolos de más bajo nivel como el IP.
* Tipo SOCK_SEQPACKET: tiene las características del SOCK_STREAM pero
además el tamaño de los mensajes es fijo.
El dominio de un socket indica el formato de las direcciones IP que sigue, así como los
protocolos que utilizará el mismo. Los dominios pueden ser:
*AF_UNIX: el cliente y el servidor son procesos de una misma máquina.
*AF_INET: el cliente y el servidor pueden estar en cualquier máquina de Internet.
*AF_PUP o AF_NS: cliente y servidor deben estar en una red de Xerox Corporation.
50
*AF_APLETALK: red Appletalk de Apple Computer Corporation.
*AF_CCITT: para protocolos CCITT, protocolos X25, etc.
Puede darse el caso de que un tipo de socket soporte varios protocolos para un mismo
servicio. Por ejemplo, podría tener más de un protocolo para entrega de datagramas sin
conexión. El programador puede escoger el protocolo específico a través del tercer
parámetro de la llamada a socket.
La creación del socket, por sí misma no crea una asociación con ninguna dirección local o
de destino. Para asignarle a un socket servidor una dirección de puerto definida debe
llamarse a una función especial encargada de realizar el enlace: bind (socket, direccion_local,
longitud_de_dirección). Para esto debe especificarse el descriptor del socket previamente
creado, una estructura que provee la dirección local a la que el socket deberá enlazarse y un
argumento adicional que indica la longitud de las direcciones medidas en octetos.
En lugar de dar la dirección solamente como una secuencia de octetos, los diseñadores
eligieron utilizar un estructura para las direcciones. Esta estructura se denomina
genéricamente sockaddr y comienza con un campo de 16 bits que identifica el conjunto de
protocolos al que pertenece la dirección, seguido por la dirección que puede ser de hasta 14
octetos (grupos de 8 bits). Cada familia de protocolos define cómo se usarán los octetos en
el campo de dirección. Para TCP/IP, la dirección de socket se conoce como sockaddr_in e
incluye una dirección IP y un número de puerto de protocolo.
Por razones semejantes, el proceso cliente debe llamar a una función para establecer una
conexión antes de que pueda transferir datos a través del socket recientemente creado:
connect (socket, dirección_destino, longitud_de_dirección). La llamada a esta función
requiere argumentos similares que la utilizada para enlazar el socket servidor con un número
de puerto. En este caso se requiere el descriptor de socket que se refiere al socket servidor.
La estructura de dirección se refiere a la dirección de destino a la que deberá enlazarse y se
requiere igualmente la longitud de la dirección de destino medida en octetos.
51
En el caso de utilizar TCP, la función anterior intenta realizar la conexión con el destino
y en caso de no lograrlo devuelve un error. En cambio, si se utilizan servicio sin conexión, la
función no hace más que almacenar localmente la dirección de destino.
Para que un servidor acepte conexiones, se requiere realizar llamadas a un par de
funciones adicionales. La primera, listen (socket, longitud_cola), sirve para especificar la
longitud de la cola de espera que podrá manejar el servidor en ese socket. Si una petición de
conexión llega en el momento en el que el servidor está aún ocupado atendiendo a la anterior,
la petición entrante quedará en la cola de espera, en lugar de ser rechazada.
La
segunda
función,
accept
(socket,
puntero_sockaddr_cliente,
puntero_longitud_dirección_cliente) sirve para aceptar las conexiones entrantes. La función
accept se bloquea hasta que el servidor reciba una petición de conexión. En ese momento
crea un socket sin nombre con las mismas características que el socket servidor original, lo
conecta al socket cliente y devuelve un descriptor de fichero que puede ser utilizado para la
comunicación con el cliente.
Proceso servidor
Crea un socket con nombre
Asignarle una dirección al socket.
Proceso cliente
socket() 52
bind()
Crea un socket
sin nombre
socket()
Realiza una petición
de
conexión
al
servidor
connect()
Figura 2.11 Proceso de comunicación entre sockets
53
CAPÍTULO 3: Diseño del sistema de transmisión de datos.
La función fundamental que debe cumplir el sistema a diseñar es hacer llegar los
mensajes de sistema de una central Meridian a un servidor, para mostrar esta información en
una página de Internet. De acuerdo con lo visto en el marco teórico, se desprenden tres
posibilidades distintas para realizar la conexión, como se muestra en la siguiente figura. La
primera consiste en utilizar una computadora para recibir los mensajes de la central y
enviarlos al servidor por TCP/IP. La segunda opción realiza la misma opción, pero
utilizando una caja convertidota de RS-232 a RJ-45. La tercera alternativa es conectar la
central directamente a la red local.
Figura 3.1 Diferentes esquemas de conexión
54
En este capítulo se realiza el diseño del sistema de captura y transmisión de los
mensajes y se deja para el siguiente capítulo lo correspondiente al diseño de la aplicación
Web. Como primer paso se establecen las especificaciones y restricciones que requiere el
sistema para luego escoger el método que mejor se adecúe a esas condiciones.
3.1 Requisitos de diseño
En vista de que se espera implementar el sistema en empresas privadas y/o entidades
gubernamentales que posean una central Meridian 1, es necesario cumplir con ciertos
requisitos para cuidar los recursos tanto de la central como de la red de la empresa. Además
se tiene que cumplir otros requisitos que hacen que el sistema sea atractivo y funcional:
Seguridad
El sistema debe ser seguro. El acceso a la central debe ser evitado, con el fin de no correr
el riesgo de que otras personas alteren la configuración de la central del cliente, ni que tengan
acceso a su base de datos.
Estabilidad
El sistema para capturar y transmitir la información debe ser estable. Debe ser capaz de
funcionar continuamente 24 horas todos los días. Para cumplir con este aspecto, es
necesario que tanto el hardware como el software utilizado para implementar el sistema sean
capaces de trabajar ininterrumpidamente. Además se requiere que la conexión a Internet por
la cual se va a realizar la transmisión también sea estable.
55
Respaldos
Es necesario que el sistema realice copias de seguridad de los mensajes capturados de la
central, de esta manera se tendrá un respaldo en caso de que falle la conexión con el servidor
y así los datos podrán ser retransmitidos.
Sencillez
El diseño del sistema debe ser lo más sencillo posible. Esto facilita la implementación
del mismo, su operación y la realización de mejoras futuras o ampliaciones para incrementar
su funcionalidad. Si el diseño es sencillo, la detección y solución de fallas durante las
pruebas es más rápida.
Además, hay que tomar en cuenta que el número de clientes que deseen implementar el
sistema de supervisión en su empresa podría aumentar con el tiempo, por lo que aumentaría
también la demanda de procesamiento del servidor. Si el sistema es sencillo, el servidor
podrá satisfacer las demandas de todos los clientes en una forma fácil, sin utilizar muchos de
sus recursos.
El hecho de utilizar pocos recursos de hardware en la implementación del sistema tiene
una repercusión económica importante, debido a que permite utilizar los equipos existentes
en otras aplicaciones conjuntas, o bien, comprar equipos menos costosos (la capacidad de
una computadora en cuanto a memoria, velocidad de procesador y disco duro son aspectos
determinantes en su precio).
56
Modularidad
Se desea que el sistema esté compuesto por módulos, cada uno con una función bien
definida. Esto simplifica la tarea de diseño y la hace más ordenada, a la vez que facilita
futuras reimplementaciones o modificaciones de alguno de los módulos.
Claridad
Todos los módulos que se utilicen en el diseño deben tener razones que los justifiquen y
debe tenerse un conocimiento profundo de su estructura y funcionamiento, para garantizar
el funcionamiento del sistema total y también para favorecer las modificaciones futuras o
adaptaciones necesarias a la hora de su implementación.
El diseño debe estar detalladamente documentado, para facilitar la interpretación del
mismo por parte de terceros.
3.2 Escogencia de la línea a seguir
El proyecto se diseñó siguiendo la línea de una computadora “cliente” encargada de
recibir los mensajes de la central y enviarlos al servidor de páginas Web vía TCP/IP. La
opción de conectar directamente la central a la red local se desechó por motivos de
seguridad, ya que esa conexión utiliza SNMP, lo cual implicaría que la central queda
protegida del exterior únicamente por la seguridad de la red local (el firewall) y es
susceptible a ataques provenientes de la misma red interna. La alternativa de una caja
convertidota de RS-232 a RJ-45 no fue descartada por completo, sin embargo, implica un
gasto adicional y no presenta las facilidades de procesamiento de una computadora.
57
Se estableció que esta computadora debía tener el sistema operativo Linux, y todo el
software utilizado debía ser libre. Esto se hizo por dos razones principales: la primera, la
estabilidad y seguridad que ofrecen los sistemas basados en Unix, y la segunda, el software
libre no representa ningún costo adicional para la empresa.
Además, el hecho de tener una computadora realizando esta función presenta las
siguientes ventajas:
•
Se puede procesar las alarmas y otros datos provenientes de la central.
•
Permite realizar copias de seguridad de la información recibida, así como
redireccionarla hacia distintos lugares.
•
Es posible crear una red privada virtual, así como otros mecanismos para aumentar
la seguridad del sistema.
•
La computadora no tiene grandes exigencias de procesamiento, lo cual permite
utilizar una computadora vieja, cuyo costo es bastante bajo en comparación con una
caja convertidora de RS232 a TCP nueva.
3.4 Configuración de la central Meridian 1.
Aquí se describe la configuración que debe realizarse en la central para que envíe los
mensajes a través del puerto serie. Los principales requisitos de la configuración a realizar
son:
•
Salida con formato, para facilitar su identificación e interpretación de los datos
•
Puerto de solo salida, como medida de seguridad, para que nadie sea capaz de entrar
en la configuración de la central aunque tengan acceso a la computadora cliente.
58
Para el primer punto, basta cargar el LD117, que es el programa encargado del manejo de
fallas, y escribir el siguiente comando:
=> CHG FMT_OUTPUT ON
El comando anterior activa el formato de los mensajes de salida. Con respecto a la
seguridad del sistema, el programa encargado es el LD17. Como mínimo debe realizarse las
siguientes correcciones:
Prompt
Respuesta del
del sistema
usuario
REQ
CHG
TYPE
ADAN
USER
X MTC
comentario
deshabilita el puerto como unidad de
mantenimiento.
X SCH
deshabilita la capacidad de cambiar cualquier servicio o
base de datos
3.5 Diseño del programa para transmitir datos
Luego de plantear el funcionamiento en forma esquemática se redactaron códigos en el
lenguaje de programación Perl para las distintas etapas del sistema. La escogencia del
59
lenguaje se realizó tomando en cuenta recomendaciones de profesores de la escuela de
Ingeniería Eléctrica, y a la vez se prefirió este lenguaje sobre otros posibles por razones
como facilidad y rapidez a la hora de escribir el código fuente, facilidad para encontrar y
usar módulos y la versatilidad del lenguaje, ya que Perl es muy completo en todas las etapas
del sistema, lo que permitió escribir la totalidad de los programas en el mismo lenguaje.
3.5.1 Especificaciones del comportamiento del programa
Los módulos básicos que componen el sistema son: un módulo encargado de capturar
los mensajes del puerto serie de la Meridian, un módulo que actúa como proceso cliente y
un tercer módulo actuando como proceso servidor (este último ubicado en el servidor de la
página Web). Además, se incluyen módulos adicionales para brindar funciones de registro y
bases de datos. La siguiente figura presenta un diagrama funcional del sistema:
60
Meridian
Captura de Mensajes
lee_puerto.pl
Identificación
Computadora 1
corriendo Linux
Registro
Proceso Cliente
Cliente::enviar()
Red local
Internet
Proceso Servidor
servidor.pl
Identificación del cliente
Servidor
Database::actualiza_base()
Actualización de Bases de datos
61
Figura 3.2: Diagrama funcional básico del sistema de transmisión.
Según el diagrama anterior, hay un bloque encargado de capturar cualquier mensaje que
emita la central Meridian. Este es un ciclo infinito, para evitar la pérdida de algún mensaje,
éste se ubica en el programa principal, lee_puerto.pl (como apéndice se incluyen los listados
de todos los programas del sistema de transmisión de datos, en forma electronica). Los
mensajes así obtenidos se identifican y aquellos que cumplen el formato establecido se
guardan en un registro de seguridad y se envían al módulo cliente, para que los transmita vía
sockets al servidor.
El proceso cliente es una subrutina que es llamada cada vez que el programa principal
identifica un mensaje con formato válido. Esta subrutina se llama enviar() y se incluyó en un
módulo llamado Cliente, por lo que su llamado en el programa principal debe hacerse como
Cliente::enviar(mensaje). Junto con el mensaje que se desea enviar se pasa como argumento
un número de identificación de la central, que es útil para individualizar las bases de datos
posteriormente.
La subrutina enviar() se encarga de crear un socket que se conecta con el servidor.
Igualmente debe haber un proceso servidor que atienda las peticiones de conexión y reciba
los mensajes enviados, éste es el programa servidor.pl. Los mensajes recibidos se pasan
como parámetro al módulo encargado de identificar y registrar los mensajes en bases de
datos. Esto es necesario porque se asume que se tendrán diferentes clientes, y cada uno debe
escribir en su propia base de datos. Esta funcionalidad está implementada en la subrutina
actualiza_base(), en el módulo Database.
Por último, la presentación de la base de datos se realiza en forma dinámica, a través de
un CGI que acepta algunos parámetros por parte del usuario para presentar y filtrar la
información en la página Web. El diseño HTML y de los cgi es el tema del siguiente
capítulo.
62
A continuación se detalla el diseño de los módulos necesarios para la transmisión de los
mensajes por Internet y su incorporación a la base de datos. El primer programa,
lee_puerto.pl contiene los módulos de captura de mensajes, identificación, registro y
proceso cliente:
3.5.2 Diseño del módulo de captura de mensajes de la Meridian 1.
El módulo de captura de los mensajes de la Meridian es un ciclo infinito que espera un
mensaje en el puerto serie. Cuando aparece cualquier mensaje, éste es identificado para
comprobar que se trata de un mensaje de interés.
Bajo el sistema operativo Linux, esto se realiza primeramente con un redireccionamiento
del puerto serie hacia un descriptor. Luego de eso el procedimiento es idéntico al de
apertura y lectura desde un archivo.
La principal dificultad corresponde al ajuste de los parámetros de transmisión del
puerto, como son la velocidad, bits de inicio, bits de parada, paridad, bits de datos y control
de flujo. Sin embargo, estos ajustes son realizados fácilmente a través de métodos incluidos
en el módulo Device::SerialPort, el cual es de código libre y se puede obtener de la página de
la CPAN.2
El módulo define la clase SerialPort. Como cualquier clase, lo primero que hay que hacer
es crear un objeto de esa clase, mediante el constructor new (lee_puerto.pl, línea 27).
Otros métodos útiles definidos en la clase son: baudrate(), parity(), databits(),
stopbits(), hanhshake() los cuales ajustan los parámetros de velocidad, bits de paridad, bits
de datos, bits de parada y control de flujo, respectivamente.
Una vez configurados los parámetros, se realiza el redireccionamiento mediante la
función open y se puede leer del puerto como si se hiciera de un archivo. En este caso es un
2 www.cpan.org
63
archivo especial, pues no contiene el carácter de fin de archivo, por lo que leer del archivo se
convierte en un ciclo infinito que continuamente espera mensajes (lee_puerto.pl, línea 50).
64
3.5.3 Diseño del módulo de identificación y registro de los mensajes.
Cualquier mensaje que se obtenga en el ciclo anterior es guardado en un registro local
(lee_puerto.pl, línea 59). Esto se realiza fácilmente: primero se abre el archivo con open
FILEHANDLE, nombre de archivo y posteriormente se “imprime” en FILEHANDLE,
como print FILEHANDLE “mensaje a imprimir”. FILEHANDLE se conoce como el
descriptor del archivo.
Sin embargo, no todos los mensajes serán enviados al servidor, ya que pueden haber
mensajes que no sean alarmas. Por eso, cada mensaje es identificado para comprobar que
cumple el formato de alarma establecido. El formato de las alarmas es el siguiente:
<severidad> <id> <fecha> <hora> <no sec> <evento> <numero de secuencia>
Operator data:<mens op>
Expert data:<mens exp>
La severidad se da según el número de asteriscos en el campo severidad. Los campos
que se desean presentar son los que se encuentran en la primera línea. La identificación del
formato se realiza con la siguiente expresión regular (lee_puerto.pl linea 54):
/\** \w+ \d\d\/\d\d\/\d\d \d\d:\d\d:\d\d \d+/
La expresión anterior será verdadera si se cumple el patrón, que quiere decir lo siguiente:
\** :
Cero o más asteriscos . Ej: ***
\w+ :
Uno o más caracteres alfanuméricos. Ej.: BUG035
d\d\/\d\d\/\d\d : Formato de la fecha, dd/mm/aa. Ej.: 03/05/05
65
\d\d:\d\d:\d\d : Formato de la hora, hh:mm:ss. Ej.: 12:45:50
\d+: Uno o más dígitos, corresponde al número de secuencia de la alarma.
Se puede observar que cada mensaje que cumple con el formato es enviado junto con un
número de identificación ($id). Esto es muy útil para organizar la información en bases de
datos separadas al llegar al servidor.
3.5.4 Diseño del proceso socket cliente.
En esta sección se expone la propuesta para la implementación del proceso socket
cliente, el cual forma parte del sistema de transmisión de mensajes por Internet.
Los lineamientos expuestos en la sección 2.4 son válidos, sin embargo aquellos se refieren a
funciones de más bajo nivel que las implementadas en el módulo IO::Socket, incluido en el
núcleo de Perl.
El módulo IO::Socket usa en el fondo las funciones definidas en el módulo Socket, las
cuales coinciden con las vistas en la sección 2.4. No obstante, IO::Socket es una clase
descendiente de IO::Handle, por lo que hereda todos sus métodos, lo cual permite que al
crear un objeto de tipo IO::Socket, podamos tratarlo como si fuera un archivo.
Otra ventaja de utilizar la clase IO::Socket es la posibilidad de usar la clase derivada
IO::Socket::INET, la cual permite crear sockets de tipo INET, en una forma mucho más
fácil. De hecho, es posible establecer todos los parámetros del socket al momento de crearlo,
debido a que su constructor new() acepta que se le pasen, como la dirección IP remota, el
puerto al cual debe conectarse y el protocolo que debe usarse (Cliente.pm, línea 16).
Al crear el objeto, se hace una llamada a socket() para crear el socket, pero además se
llaman las otras funciones para realizar la conexión, como connect() en el caso del cliente y
bind(), listen() y accept() en el caso del servidor. Por esta razón, al crear un objeto de esta
66
clase, el mismo hace referencia a un socket ya inicializado y puede utilizarse directamente
para trasmitir datos (Cliente.pm, línea 24).
3.5.5 Diseño del módulo servidor
La creación del proceso servidor es muy similar a la creación del cliente, con el módulo
IO::Socket::INET (servidor.pl, línea 21). Para este caso, simplemente hay que incorporar
los parámetros de número de puerto donde se van a establecer las conexiones (LocalPort)y
el número de conexiones que pueden esperar en la cola (Listen). Es recomendable agregar el
parámetro ReuseAddr y ReusePort para permitirle al servidor reutilizar la dirección y el
puerto antes de llamar a bind().
El servidor que se implementa a continuación tiene capacidad de atender únicamente una
conexión al mismo tiempo. Las conexiones entrantes durante el tiempo en el que el servidor
está atendiendo otra conexión quedan en una cola de espera, si la longitud de la cola lo
permite. Esto es necesario debido a que cada mensaje que entra queda guardado en un
registro particular y una base de datos general. Si hubiesen dos o más conexiones abiertas
simultáneamente, cada una estaría abriendo y escribiendo simultáneamente en un mismo
archivo, lo cual puede causar resultados inesperados. Además, el hecho de que se atienda
una conexión a la vez no representa una desventaja significativa, debido a que el tiempo que
dura cada conexión es el necesario para abrir un archivo y escribir una nueva entrada en él,
por lo que se espera que las conexiones en la cola sean rápidamente atendidas y por lo tanto
la longitud de la cola no sea extremadamente extensa.
3.5.6 Diseño del módulo para escribir en la base de datos
Como sistema para almacenar los mensajes enviados al servidor se utilizan archivos de
texto planos, donde cada línea del archivo corresponde a una alarma diferente, y el número
67
de campos de cada entrada es constante. Cada programa cliente que se conecta al servidor
tiene preasignado un número de identificación, lo que le permite al servidor escoger un
archivo diferente para cada central.
El número de identificación de la central se escogió de tres dígitos, de los cuales los dos
primeros corresponden al número de identificación de la empresa propietaria, y el último
dígito corresponde al número de central dentro de la empresa. Este sistema tiene capacidad
para 100 empresas diferentes, cada una con un máximo de 10 centrales.
El sistema escribe en tres bases de datos diferentes: una llamada database_pbx$id, donde
$id es el número de tres cifras correspondiente a la central, otra llamada
database_empresa$id_empresa, donde $id_empresa es el número de dos cifras propio de
cada empresa y la última, database_telectro, donde se escribe toda la información
(Database.pm, líneas 22, 26 y 28). Esta organización permite tener respaldos de datos
separados para cada central y cada empresa; y permite además que una empresa que tenga
más de una central pueda observar en la misma página las alarmas de todas sus centrales de
una forma más fácil, como se verá en el siguiente capítulo.
Hay un segmento de código (Database.pm, línea 33) que realiza una sustitución del
número de asteriscos en el campo de severidad de la alarma por la severidad que representa:
ninguna, menor , mayor o crítica.
Antes de escribir cualquier entrada nueva, el programa comprueba que la longitud del
archivo no exceda cierto límite (Database.pm, línea 41). Esto se realiza principalmente por
motivos de visualización de la página, ya que resulta molesto que al abrir la página el
número de mensajes que aparece sea exagerado.
Por ahora, si se sobrepasa el límite establecido, el mensaje más viejo es eliminado antes
de escribir el nuevo mensaje, pero esta funcionalidad puede ser fácilmente modificada para
que el programa reescriba esos mensajes en un registro de mayor extensión.
68
CAPITULO 4: Diseño de la aplicación Web
Partiendo del diseño que se realizó del programa para la transmisión de datos
encargado de la captura, transmisión y almacenaje en base de datos plana de los mensajes
de la central Meridian hasta un servidor, se diseñó una aplicación Web para permitir
visualizar en tiempo real estos mensajes en forma ordenada, amigable y con algunas
facilidades de búsqueda, filtrado y visualización. También esta aplicación se diseñó de tal
forma que cuando el usuario ingrese su nombre y clave la aplicación escoja en forma
automática e imperceptible al usuario la base de datos correspondiente entre las diferentes
bases de datos que existen. De manera que cumpliera las anteriores características se creó el
siguiente sistema utilizando CGIs y HTML:
Genera código HTML
de pagina principal
Nombre de la
base de datos
index.html
login.cgi
baduser
/badpass.html
HTML
cabeza.cgi
usuario
Calve
marco 1
Nombre de la
base de datos
usuario/clave
incorrecto
HTML
leerlog.cgi
marco 2
Nombre de la base de datos
+ opciones de búsqueda
Figura 4.1: Esquema de funcionamiento de la aplicación Web
69
El usuario ingresa a index.html que le solicita el nombre y la clave, estos datos son
pasados a login.cgi que verifica la existencia del usuario y la correcta escritura de la clave.
login.cgi crea una pagina principal hecha de dos marcos; en el superior carga la cabeza.cgi
que contiene las opciones de búsqueda y en el inferior carga leerlog.cgi que muestra el
contenido de la base de datos, login.cgi pasa como parámetro el nombre de la base de datos
a leerlog.cgi y a cabeza.cgi. Es indispensable que cabeza.cgi tenga el nombre de la base de
datos ya que cuando se realiza una búsqueda es necesario volver a llamar a leerlog.cgi con
las opciones de búsqueda y el nombre de la base de datos, ya que este sistema debe
funcionar de forma multiusuario o sea que tanto el programa cabeza.cgi como leerlog.cgi
pueden estar siendo utilizados al mismo tiempo por diferentes clientes y la única forma
diferenciar la base de datos correcta es pasándola como parámetro.
El diseño HTML se realizó con la asistencia del programa DreamWeaver de
Macromedia. Para el diseño de los módulos CGI se utilizó el lenguaje de programación
PERL.
4.1 Módulo index.html
Se visualiza de la siguiente manera:
Figura 4.2: Captura de pantalla de index.html
70
Este módulo constituye el inicio de la aplicación y su función principal consiste en
obtener el nombre de usuario y su clave y pasarlos como parámetros a login.cgi. El listado
completo de todos los códigos HTML se encuentra en el CD de apéndices.
4.2 Módulo login.cgi
Este modulo recibe el nombre de usuario y su clave como parámetros con los que
realiza el siguiente procesamiento
NO
Existe el usuario?
Corre baduser.html; es igual a
index.html pero con un mensaje de
error
SI
NO
SI
Clave correcta?
Corre badpass.html; es igual a
baduser pero cambia el mensaje
de error
Nombre de base de datos = nombre de la base
de datos del usuario ingresado
Se imprime el código HTML que crea la pagina principal con
2 marcos; en el superior se llama a cabeza.cgi y en el inferior
se llama leerlog.cgi En el llamado de estos dos CGIs se
incluye como parámetro el nombre de la base de datos
Figura 4.3: Diagrama ASM de login.cgi
71
Su implementación en lenguaje PERL se encuentra en el CD de apéndices.
4.3 Módulo cabeza.cgi
Este modulo imprime el código HTML necesario para visualizar lo siguiente:
Figura 4.4: Captura de pantalla de cabeza.cgi
La figura anterior constituye la cabeza o marco superior de la página principal. Este
contiene las opciones de búsqueda, omisión y ordenamiento de la base de datos. El primer
menú sirve para escoger entre búsqueda o omisión, en el campo de texto se escribe la(s)
palabra(s) que se desean buscar u omitir, en el segundo menú se escoge entre las columnas:
central, severidad, código alarma y fecha que es donde se realizaría la búsqueda u omisión
y en el tercer menú se escoge si se desea visualizar las entradas de la base de datos en orden
de severidad (de critica a menor) o en orden de fecha (de primero el evento más reciente).
Este módulo pudo haber sido un HTML estático, pero fue necesario hacerlo un CGI
para poder pasar el parámetro de nombre de la base de datos al modulo leerlog.cgi
72
4.4 Módulo leerlog.cgi
Este modulo es el más complejo y poderoso de todos los vistos en esta sección, tiene la
capacidad de generar el código HTML necesario para presentar una base de datos plana de
cualquier tamaño en forma de una tabla. Para generar este código HTML se basa en una
plantilla (plantilla.html, ver CD de apéndices), lo que permite fácilmente realizar
modificaciones visuales a la tabla. El nombre de la base de datos se le pasa como parámetro
lo cual permite que este programa sea capaz por si mismo de visualizar cualquier cantidad
de bases de datos diferentes, por lo que cualquier cantidad de usuarios pueden estar
utilizando el programa al mismo tiempo y visualizando resultados distintos.
También es el que se encarga de realizar las búsquedas, omisiones y ordenamiento,
para lo que recibe los siguientes parámetros con los siguientes posibles valores:
Tabla 4.1: Parámetros y sus posibles valores en leerlog.cgi
Parámetro
Posibles valores
archivo
database_XXXX
ordenar
fecha o severidad
tipo
buscar u omitir
dato
XXXX
columna
columna0,
columna1,
columna3, columna4
Y realiza el siguiente procesamiento:
73
columna2,
Datos = contenido de la base de datos
Se le da vuelta a la base de datos para que los últimos datos ingresados que son
los mas recientes queden de primeros y así quede ordenado por fecha (que es el
ordenamiento por defecto)
SI
NO
ordenar =
severidad?
Datos1 = buscar “criticas” en dato
Datos2 = buscar “mayores” en dato
Datos3 = buscar “menores” en dato
Datos4 = buscar “ningunas” en dato
Datos = unir Datos1 + Datos2 + Datos3
+ Datos4
NO
Datos = cada uno de las
palabras que contiene dato.
Para cada una de ellas:
tipo = buscar?
Datos = Datos –
entradas que
tengan “datos”
en “columna”
SI
Datos = entradas
que tengan
“datos” en
“columna”
Generar tabla a partir de
Datos
Figura 4.5: Diagrama ASM de leerlog.cgi
En el siguiente capítulo se incluye un ejemplo de utilización.
74
Capítulo 5: Guía para la instalación y el uso
La propuesta de diseño realizada en los dos capítulos anteriores fue probada y cumplió
con la funcionalidad deseada. Se llevaron a cabo simulaciones por medio de programas que
emulaban el comportamiento de la central, una calculadora HP48 que emite mensajes a
través de su puerto serie y finalmente una central telefónica real.
Las pruebas se realizaron sobre varios sistemas operativos: para la computadora cliente
se utilizó Linux Debian Woody, Debian Sid y Mandrake 9.1, todos con kernel 2.4 o
superior. Para el servidor de páginas Web se utilizó apache sobre los mismos sistemas
operativos mencionados y además se probó sobre los sistemas OSX 10.2 y 10.4 de Apple.
Todas las pruebas tuvieron resultados positivos.
El sistema funciona en forma estable, eficiente y rápida. Además, la seguridad de la
central está garantizada, de acuerdo con lo visto en el capítulo 3.
Sin embargo la
transmisión de datos por Internet no es totalmente segura por lo que se recomienda tomar
medidas de seguridad antes de implementar el sistema (en el siguiente capítulo se detallan
las recomendaciones al respecto).
No obstante, el sistema puede implementarse en forma segura si se realiza en una red
privada (o en una red privada virtual) que esté protegida mediante un firewall. Para poner
en marcha la propuesta se requiere lo siguiente:
5.1 Requisitos de Hardware y Software
Se determinó que la computadora cliente debe contar con las siguientes características
mínimas. Preferiblemente esta computadora debe utilizarse únicamente como computadora
cliente del sistema y para la administración local de la central.
75
Hardware:
Procesador Pentium 75Mhz.
24 Mb de memoria RAM.
Disco Duro de 450 Mb.
Interfaz RS-232.
Tarjeta de Red 10/100 Base T.
UPS propia.
Software:
Sistema Operativo Linux, kernel 2.4 o superior
Perl 5.8.4.
Módulo DeviceSerialPort.
El servidor debe contar, al menos, con el siguiente equipamiento. Evidentemente si se va
a implementar el sistema dentro de una red local, la computadora cliente puede ser utilizada
como servidor de páginas web, por lo que se necesitaría únicamente una computadora que
cumpla con los requisitos de hardware y software tanto del cliente como del servidor.
Hardware:
Procesador Pentium II 300 MHz.
128 Mb de memoria RAM.
Disco Duro de 4 Gb.
Tarjeta de Red 10/100 Base T.
UPS propia
76
Software:
Sistema Operativo Linux, kernel 2.4 o superior
Servidor de páginas web Apache.
Perl 5.8.4
Para la computadora que actúa como servidor es todavía más recomendable que no sea
utilizada como estación de trabajo, por lo que no necesita el sistema gráfico de Linux
(sistema X) sino solamente el sistema básico de consola.
5.2 Instalación del sistema
Antes de que la computadora cliente pueda enviar los mensajes al servidor, en éste
segundo debe estar ejecutándose tanto el servidor de páginas web apache como el programa
servidor.pl. En el sistema Debian Linux, el apache utiliza las páginas web ubicadas en el
directorio /var/www, mientras que los cgi que puede ejecutar deben ubicarse en /usr/lib/cgibin. La estructura de archivos y directorios debe quedar de la siguiente manera:
/var/www/
index.html
baduser.html
badpass.html
imagenes/
flash/
css/
77
/usr/lib/cgi-bin/
plantilla.html
login.cgi
cabeza.cgi
leerlog.cgi
Subrutinas.cgi
servidor.pl
Database.pm
database_telectro
database_pbx000
database_empresa00
Los archivos deben contar con los permisos necesarios para verse, ejecutarse y
modificarse correctamente, según sea el caso. Las bases de datos correspondientes a cada
empresa y cada central deben existir para que el programa servidor.pl puede ejecutarse.
Cuando se requiera agregar una nueva empresa o una nueva central, debe realizarse lo
siguiente:
•
Crear los archivos necesarios, de la forma database_pbxXYZ y
database_empresaXY.
•
Agregar el nombre de la central al hash %nombres (Database.pm, línea 39).
•
Asignarle al programa lee_puerto.pl correspondiente a la nueva central el número de
identificación $id XYZ (lee_puerto.pl, línea 22).
El puerto donde el servidor espera conexiones es el 9000, pero puede cambiarse si es
necesario (servidor.pl, línea 19).
Una vez que el servidor ha sido configurado y está ejecutando el programa servidor.pl,
cada cliente puede iniciar el envío de mensajes. La computadora cliente requiere
78
únicamente de dos archivos: Cliente.pm y lee_puerto.pl. Las principales variables que hay
que ajustar en estos archivos son:
•
El número de identificación de la central (lee_puerto, línea 22).
•
El directorio donde se ubica el registro de respaldo (lee_puerto, línea 23).
•
Los parámetros de transmisión del puerto (lee_puerto.pl, línea 33).
•
La dirección IP del servidor (Cliente.pm, línea 16).
•
El puerto de conexión (Cliente.pm, línea 19).
Si por algún motivo se deja de ejecutar el programa servidor.pl, cada programa
lee_puerto.pl finalizará cuando llegue un mensaje del puerto serie, debido al error de
conexión. En este caso hay que volver a ejecutar lee_puerto.pl nuevamente después de
que se reestablezca la conexión con el servidor.
5.3 Uso de la aplicación web
•
Inicio
!
Index.html constituye el inicio de la aplicación web, en el caso en el que este
sistema se vaya a instalar en un sitio web ya diseñado el nombre index.html
no prodrá ser utilizado debido a este será el nombre de la página principal,
por lo que deberá de cambiarse el nombre y realizar un enlace desde la
página principal para que el cliente pueda accesar desde ahí.
!
Index.html presenta el siguiente formulario donde se debe introducir el
nombre y la clave de usuario.
79
Figura 5.1: Página de inicio
•
Después de ingresar el nombre de usuario y la clave correctos se presentan las
alarmas (marco inferior) y las opciones de busqueda (marco superior). De forma
predeterminada se presentan todas las alarmas en orden de fecha.
•
Figura 5.2: Ejemplo de ordenamiento por defecto
80
!
Opciones de busqueda y visualización
!
Este sistema nos permite realizar una búsqueda u omisión (filtrado)
de una o más alarmas por alguna de sus características (Central,
Severidad, Codigo Alarma, Fecha, Hora, # Evento)
!
En la primera casilla (de izquierda a derecha) de selección el usuario
puede escoger entre buscar u omitir
Figura 5.3: Opciones de búsqueda o filtrado
!
En el espacio siguiente (caja de texto) se debe de introducir la
palabra o las palabras (separadas por espacios) que se desean buscar
u omitir
!
En la siguiente casilla se debe de seleccionar la característica de la
alarma por la que se va realizar la búsqueda u omisión.
Figura 5.4: Característica a filtrar
81
!
En la siguiente casilla se escoge si los resultados se desean visualizar
de forma ordenada por fecha (de primero el evento más reciente) o
por severidad (de primero los eventos con severidad crítica)
Figura 5.5: Opciones de ordenamiento
!
Asi por ejemplo si se desea buscar las alarmas mayores y menores y
presentarlas de forma ordenada por severidad se modifica las casillas
de la siguiente forma
Figura 5.6: Ejemplo de una búsqueda
y se obtienen los siguientes resultados
Figura 5.6: Resultado de la búsqueda de ejemplo
•
También es posible ordenar la tabla sin realizar ninguna búsqueda o
filtrado. Para esto simplemente se debe dejar la caja de texto en blanco
y especificar el orden que se desea para la tabla (por fecha o severidad)
82
CAPÍTULO 6: Conclusiones y Recomendaciones
El proyecto realizado cumple satisfactoriamente con el objetivo general planteado,
el cual fue diseñar un sistema para la supervisión de centrales telefónicas a través de
Internet. El sistema está enfocado a la transmisión de mensajes de las fallas ocurridas en
una central hacia un servidor, donde tales mensajes son presentados en una página Web.
Como resultado del diseño de los diferentes módulos que constituyen el sistema
propuesto se obtuvo una aplicación que es funcional, útil y fácil de implementar. Además
es flexible, en cuanto permite que se mejoren o agreguen nuevas funcionalidades.
El proyecto está basado en la interrelación de módulos de distinta naturaleza y
función. Básicamente está constituido por tres bloques: el primero encargado de capturar
los mensajes que emite la central a través de su puerto serie. A continuación está el bloque
de transmisión de datos por Internet, el cual está constituido por un socket cliente y otro
servidor. Por último, hay un bloque encargado de la presentación dinámica de la
información en formato HTML, lo que permite que el usuario final acceda a esta
información por medio de cualquier browser.
Para el desarrollo de los códigos se utilizó el lenguaje de programación Perl, bajo el
sistema operativo Linux. Se demostró que el lenguaje de programación escogido es muy
versátil y ofrece una amplia variedad de funciones y módulos que facilitó en gran medida la
redacción de los códigos, como por ejemplo los módulos DeviceSerialPort, IO::Socket y
CGI.
Sin embargo, se observó que Perl es un lenguaje que trabaja con scripts, lo cual deja
el código fuente expuesto y podría ser modificado por terceras personas.
La seguridad de la central telefónica fue un aspecto que se tomó en cuenta durante
el diseño. Para esto se configuró el puerto serie de la misma de manera que no permitiera su
utilización como terminal de mantenimiento ni diera acceso a la base de datos.
Para el almacenamiento de la información en el servidor se utilizó un conjunto de
bases de datos planas: una para cada central, otra para cada empresa (en el caso de que una
83
empresa posea más de una central) y otra general, que permite observar todas alarmas de
todas las centrales al mismo tiempo.
La aplicación Web que se diseñó utiliza la información de las bases de datos para generar
una tabla en una página HTML. Esta aplicación incluye herramientas para buscar y ordenar
la información que se presenta, lo que facilita al usuario final la interpretación de los datos
y le da un aspecto amigable.
Conviene realizar trabajos similares que supervisen el desempeño de las centrales y
permitan llevar a cabo decisiones remotas de mantenimiento.
Para aumentar la seguridad y utilidad del sistema de manera que se pueda brindar el
servicio de una forma más confiable, se tienen las siguientes recomendaciones:
•La
transmisión de la información debe ser segura. Debe impedirse que personas ajenas
decodifiquen los datos que se están enviando por Internet y tengan de esa forma
información de la central del cliente. Para esto es necesario encriptar los datos transmitidos
o crear una red privada virtual (VPN).
•También
se puede incrementar la seguridad del sistema agregando un firewall propio para el
servidor, de manera que permita únicamente las conexiones en el puerto predeterminado
(puerto 9000). Además, si las direcciones IP de los clientes se conocen de antemano, es
posible aceptar solo las conexiones provenientes de tales direcciones IP.
•Para
que un cliente pueda confiar en la información que observa en la página, la misma debe
presentar un estado de la conexión actual, tanto entre la central y la computadora cliente
como entre esta última y el servidor.
•Es
importante que el sistema sea lo más independiente posible de mantenimiento. Es
deseable que el programa haga una retransmisión de la información en caso de que se corte la
comunicación, así como que el programa se ejecute automáticamente al encender la
computadora. También es posible que el programa busque formas alternativas de
84
comunicación con el servidor en caso de que se caiga la conexión, por ejemplo que intente
conectarse vía telefónica.
•Procesar
información sobre los registros de tráfico es un aspecto que haría al sistema muy
atractivo comercialmente, ya que estos registros contienen amplia información sobre el
desempeño de la central.
•Incluir
un sistema de bases de datos más completo da la posibilidad de realizar búsquedas
más avanzadas sobre los datos registrados. Se recomienda utilizar el sistema de bases de
datos SQL.
•Es
posible modificar el programa lee_puerto.pl para que además de recibir datos de la
central sea capaz de darle comandos a la central. Esto permitiría a los técnicos programar
centrales y acceder a su configuración vía Internet. Actualmente los técnicos de Telectro
realizan configuraciones remotas de centrales ubicadas en Honduras, El Salvador, etc, pero
lo hacen vía MODEM. Esto representa un costo mucho mayor, debido a que están
realizando una llamada internacional.
•Es
conveniente evitar que el código del programa lee_puerto sea alterado. Se recomienda
buscar un método ya sea para comprobar la integridad del código o bien para ocultarlo del
usuario.
•El
sistema de aviso de alarmas puede mejorarse haciendo que el programa se encargue de
notificar a los técnicos la ocurrencia de ciertas alarmas criticas, ya sea mediante un correo
electrónico, un mensaje a un teléfono celular, etc.
•Para
mejorar la eficiencia del sistema, se recomienda que la computadora cliente tenga como
segunda función actuar como servidor de paginas Web para la red local de la empresa. Esto
aumentaría notablemente la velocidad del sistema ya que reduce el ancho de banda necesario
para la transmisión de los datos, al tiempo que reduce también el uso del procesador del
servidor principal.
85
BIBLIOGRAFÍA
Libros:
Comer, D. Redes Globales de Información con Internet y TCP/IP.
Tercera Edición, Editorial Prentice Hall, 1996.
Chinchilla, J y Aizprúa, M. Networking Essencial.
Primera Edición, Grupo Asesor en Informática S.A., Costa Rica, 1998.
Guelich, S., Shishir, G. y Birznieks, G. CGI Programming with Perl.
Segunda edición, Editorial O'Reilly, Estados Unidos, 2000.
Huidobro, J. Sistemas Telemáticos.
Primera Edición, Editorial Paraninfo, España, 1999.
Schwartz, R. y Phoenix, T. Learning Perl.
Tercera Edición, Editorial O'Reilly, Estados Unidos, 2001.
Páginas Web:
López, Juan. Tutorial HTML, www.um.es/~psibm/tutorial
Comprehensive Perl Archive Network, www.cpan.org
Los Sockets: Una Referencia Rápida, www.hackuma.com/socketz.htm
Perl Documentation perldoc.perl.org
The Apache Software Foundation, www.apache.org
The CGI Resource Index, cgi.resourceindex.com
The Perl Directory, www.perl.org
Documentos electrónicas:
Biblioteca de Consulta Encarta.
Microsoft, 2002.
Meridian Electronic Referente Library (MERL).
Nortel Networks, Canada, 2002.
86
Apéndices
Se incluye un CD con todos los programas utilizados en el desarrollo de este sistema.
87
ANEXOS: Nemónicos de los Mensajes de Error.
Se indica si el mensaje puede ser filtrado.
Nemónic
Significado
o
ACD
Automatic Call Distribution Load Management
ADD
Automatic Call Distribution Data Dump
AMH
Auxiliary Message Handler
AML
Application Module Link
AMLM Application Module Link Maintenance
ATM
Automatic Trunk Maintenance
AUD
Software Audit
AUTH Authorization Code
BERR
Bus Error Monitor
BIC
Bus Interface Circuits
BKP
Remote Backup
BRI
Basic Rate Interface
BSD
Background Signaling Diagnostic
BUG
Software Error Monitor
CCBR
Customer Configuration Backup and Restore
CCED
Core Common Equipment Diagnostic
CCR
Customer Controlling Routing
CDM
Call Detail Recording Diagnostic
CDN
Control DN
CED
Common Equipment Diagnostic
CIOD
Core Input/Output Diagnostic
CLKC
Clock Controller
CMF
Compelled Multifrequency Diagnostic
CMON Core Monitor
CND
Caller's Name Display
CNF
Conference Circuit Diagnostic
CNI
Core to Network Interface
CNV
Conversion
COM
Data Communication
88
Filtro
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Nemónic
Significado
o
CRI
Carrier Remote IPE
CSA
Command and Status Link Diagnostic
CSC
Customer Service Change
DBMT Database Media Transfer
DCH
D-Channel Diagnostic
DLO
Disk Layout
DSET
Digit Set Download
DTA
Digital Trunk Diagnostic
DTC
Digital Trunk Clock Controller Diagnostic
DTD
Dial Tone Detector Diagnostic
DTI
Digital Trunk Interface Diagnostic
DTM
Digital Trunk Maintenance
DTRK Digital Trunk Diagnostic
EDD
Equipment Data Dump
EHM
Automatic Path Retention
EMR
Emergency Key
ERR
Error Monitor (Hardware)
ESDA
Enhanced Serial Data Interface
ESDI
Enhanced Serial Data Interface
ESN
Electronic Switched Network
FHW
Faulty Hardware
FIJI
Fiber Juntion Interface
FIR
Fibre Remote IP
FMEM Flash Memory
HEX
Hexadecimal Codes and Conversion
HWI
Hardware Infrastructure Maintenance
HWR
Hardware Reset
ICU
Intercept Computer Update
IGS
Intergroup Switch and System Clock Generator
INI
Initialize
INST
Installation
IOD
Input/Output Diagnostic
ISR
Intergroup Switch and System Clock Generator Diagnostic
ITG
Integrated IP Telephony Gateway
89
Filtro
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Nemónic
Significado
o
ITS
Integrated IP Telephony Gateway
LNK
Link Diagnostic
MAT
Meridian Administration Tool
MCT
Malicious Call Trace
MEM
Memory Management
MFC
Multifrequency Compelled Signaling
MFD
Multifrequency Signaling Diagnostic
MFE
Multifrequency Signaling Diagnostic
MFK
Multifrequency Signaling for KD3
MFR
Multifrequency Receiver
MFS
Multifrequency Sender Diagnostic for ANI
MISP
Multi-purpose ISDN Signaling Processor
MOB
Mobility
MPH
Meridian Package Handler
MRB
Message Registration Block
MSDL Multi-purpose Serial Data Link
MSR
Multigroup Switch Replacement
MWL
Message Waiting Lamps Reset
NACD Network Automatic Call Distribution
NCT
Network Call Trace
NPR
Network and Peripheral Equipment Diagnostic
NWS
Network and Signaling Diagnostic
OHAS Off-Hook Alarm Security
OSM
Operating System Messaging
OSN
On-Site Notification
OVD
Overload Monitor
OVL
Overlay Loader
PCH
System Patch Reports
PMS
Property Management System Interface
PRI
Primary Rate Interface Diagnostic
PWR
Power and System Monitor
RCV
Recovery Messages
RPD
1.5Mb/s Remote Peripheral Equipment Diagnostic
RPE
2Mb/s RPE Alarm Handler
90
Filtro
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Nemónic
Significado
o
RPL
1.5Mb/s Remote Peripheral Equipment Local End Diagnostic
RPM
2Mb/s Remote Peripheral Equipment Diagnostic
RPT
System Reporting
SCH
Service Change
SCSI
Small Computer System Interface
SDL
Peripheral Software Download
SECA
Security Administration Alarm
SRPT
System Reports
SYS
System Loader
TDS
Tone and Digit Switch Diagnostic
TEMU Tape Emulation
TFC
Traffic Control
TFN
Customer Network Traffic
TFS
Traffic Measurement
TMDI
TMF
Test Multifrequencies
TRA
Call Trace
TRK
Trunk Diagnostic
TSM
Time Slot Monitor
TTY
Teletype Error Reports
VAS
Valued Added Server
VTN
Voice Port TN
XCT
Conference, Tone and Digit Switch, and Multifrequency
Senders Cards
XMI
Network to Controller Message Interface.
91
Filtro
x
x
x
x
x
x
x
x
x
x
x
x
x

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project