pasarela x25 ip - IIT - Universidad Pontificia Comillas

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
PASARELA X25 IP
AUTOR: JOSÉ LUIS PEDROSA MONTES MADRID, JUNIO 2007
Autoriza la entrega del proyecto del alumno:
José Luis Pedrosa Montes
EL DIRECTOR DE PROYECTO
Alejandro Besada Juez
Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos
David Contreras Bárcena
Fdo.: Fecha: / / Pasarela X25­IP
“Sentir gratitud y no expresarla es como envolver un regalo y no darlo”
William Arthur Ward
AGRADECIMIENTOS
Realizar este proyecto ha sido muy interesante y ha sido una gran aportación tanto académica como profesional, no obstante no ha sido una tarea sencilla y ha requerido mucho esfuerzo, el cual ha sido canalizado hacia un fin gracias a mi director de proyecto Alejandro Besada Juez, sin el cual este proyecto habría sido prácticamente imposible. A la Universidad Pontificia Comillas y en especial a la Facultad de Ingeniería Informática por haberme dado la oportunidad de realizar los estudios de Ingeniera Superior Informática, así como a los catedráticos que me impartieron clase, por haberme brindado sus conocimientos e ideas.
Dentro del marco de la universidad a David Contreras el coordinador del proyecto, por aportarme una visión profesional del proyecto, uniendo los entornos laboral y universitario. A Mario Castro Ponce, coordinador de este proyecto en sus primeros estadios y profesor durante todos mis años de carrera, sin él la pila de protocolos sería un misterio sin resolver. Quiero agradecer también a Pedro Sánchez Fuentes, antiguo alumno de ésta escuela, por su compresión en el trabajo, y el permitirme compatibilizar los estudios de mi ultimo año de carrera con el desempeño laboral en la empresa.
A mis padres José Luis y Mercedes, por el hábito que me inculcaron hacia el estudio en forma de superación y que me enseñaron que es la mejor herencia que se puede recibir.
Asimismo reconozco la contribución personal de cada uno de mis familiares y amigos, pues cada uno con su propio estilo me han ofrecido su apoyo moral y su amistad.
Aunque la memoria me traicione y no mencione a otras tantas, no son menos importantes, en momentos especiales las recuerdo y agradezco de corazón el apoyo que recibí de ellos.
José Luis Pedrosa Montes
III
Pasarela X25­IP
RESUMEN
Actualmente la tecnología X25 esta cada vez mas en desuso, a pesar de ello, en ciertos
entornos sobre todo en los relacionados con el mundo de las transacciones económicas, como
pueden ser las entidades bancarias, sigue siendo la manera estándar de establecer comunicaciones
entre distintas empresas, este es el caso del cliente de Ansib, corporación cuyo principal negocio es
el de hacer de intermediario entre los comercios, grandes superficies o entidades recargadoras de
menor tamaño y los distintos operadores de telefonía móvil, con los que se “recargan” los móviles
prepago de estas compañías.
El objetivo principal de éste proyecto es el desarrollo e implantación de una aplicación
Linux, que sirva de pasarela entre los comercios que realizan recargas y la entidad recargadora. En
la actualidad ya existe un software realizando estas funciones, sin embargo se ha elegido hacer el
desarrollo de una nueva pasarela, por los siguientes motivos:
Un movimiento global de la empresa hacia tecnologías basadas en software libre, como
por ejemplo la migración de los distintos servidores a Linux, ofreciendo sus servicios web a través
de servidores Apache ó Tomcat.
Uno de los motivos para basarse en soluciones GNU, es la posesión del código fuente,
muy necesario en un negocio que cambia con mucha rapidez, ya que con mucha frecuencia surge la
necesidad de modificar cierto comportamiento o añadir alguna funcionalidad en alguna de las
múltiples piezas que integran el sistema.
La empresa cliente no sólo acepta transacciones por X25, sino también por RTB e IP,
con diferentes protocolos para cada uno de los interfaces. Las transacciones recibidas a través de
X25 están formadas con el protocolo PRA. Este protocolo ha sido recientemente actualizado a su
versión 4, el cual ofrece mejoras significativas respecto sus versiones anteriores. Ayudando a
conseguir una mayor fiabilidad en el estado de las transacciones.
Debido al gran número de conexiones, el cliente demanda un mayor control e
información del estado de las comunicaciones, es por ello que se desarrollará un interfaz web que
muestre el estado de la misma, así como control sobre la máquina y el proceso.
José Luis Pedrosa Montes
IV
Pasarela X25­IP
ABSTRACT
Nowadays X.25 technology is becoming more and more uncommon, despite of this, in
some business, mainly in economical transactions environments, such as banks, it still is the
standard way of establishing communications between different companies. This is the case of
AnSiB's client, a corporation dedicated to intermediate between shops, malls or cell phone resellers
and the others cell phone carriers, which adds the credit on the customeraccount.
The prime goal of this project is the development and implementation of a Linux
application, which serves as a gateway between the retailers which provide the customer with credit
and the carrier.
In this moment there is already a software gateway solving this problem,
nevertheless, the coporation has decided to develop a new gateway because of the following
reasons:
A global movement of the corporation towards technologies based on open source
software, such as the migration of the different servers to Linux, offering their web services through
Apache or Tomcat server.
One of the main reasons for using GNU or GPL software is the possession of the
source code, absolutely unavoidable in a business that changes very fast, especially taking into
account that in many cases there is the need to modify a behavior or to add a function in one of the
many pieces that conform the system.
AnSiB's client not only accepts transactions through X25 interfaces, but also through
PSTN an IP with different protocols for each interfaces; in the case of the X25 interface
communications are made using a protocol called PRA. This PRA protocol has been rencently
updated to version 4, which offers relevant advantages being compared to earlier versions, one of
them is to provide with an accurate state of the transaction. Depending on the customer profile who
connects, this protocol can be also used on TCP/IP connexions. Nevertheless this question exceeds
the scope of the project.
Because of the huge amount of connexions, whether the number or the different
networks in which this corporation works on, the client demands a higher control and information
level of the system state; that is why a web interface will be developed, showing the state of the
gateway providing control over itself.
José Luis Pedrosa Montes
V
Pasarela X25­IP
José Luis Pedrosa Montes
VI
Pasarela X25­IP
INDICE
0 AnSiB Net Solutions...............................................................................................
...........................1
1 JUSTIFICACIÓN DEL PROYECTO.....................................................................
...........................4
1.1 Justificación académica.................................................................................
.............................4
1.2 Justificación económica......................................................................................................
........4
2 PLANTEAMIENTO DEL PROYECTO.........................................................................................
...5
2.1 Organigrama de los componentes............................................................................................
...5
2.2 Descripción de los integrantes...................................................................................................
.5
2.3 Estimación......................................................................................................
............................6
2.4 Presupuesto..............................................................................................................
...................6
2.5 Elección Hardware..................................................................................................................
....7
2.6 Elección Software...........................................................................................................
............9
2.7 Metodología de desarrollo.........................................................................................
...............10
2.8 Programación temporal.........................................................................................................
....13
3 ANÁLISIS DE REQUISITOS.................................................................................
........................14
4 PROTOCOLO PRA V.4.................................................................................................
..................24
4.1 Introducción..........................................................................................................
....................25
4.2 Descripción del protocolo........................................................................................................
.26
4.3 Tramas del terminal al host...........................................................................
...........................29
4.4 Mensaje de solicitud de recarga.......................................................................................
.........31
4.5 Mensaje de solicitud de recarga por tarjeta....................................................................
..........33
4.6 Anulación...........................................................................................................................
.......38
4.7 Consulta................................................................................................................
....................39
4.8 Resumen de códigos de respuestas..............................................................................
.............41
4.9 Tramas contables (fin de día)..............................................................................
.....................42
5 DISEÑO DE LA PASARELA...............................................................................
..........................45
5.1 X25 y Api Eicon................................................................................................
.......................46
5.2 Clases................................................................................................................
........................51
5.3 Aplicación Web.....................................................................................................................
....78
6 INSTALACIÓN DEL HARDWARE Y SOFTWARE.....................................................................91
6.1 Instalación Hardware.........................................................................................
.......................92
6.2 Pasarela................................................................................................................
.....................99
6.3 Bastionado del servidor...................................................................................
.......................102
6.4 Entorno Web...................................................................................................
........................105
7 FICHERO DE CONFIGURACIÓN....................................................................................
...........107
8 CONCLUSIONES........................................................................................................
..................109
BIBLIOGRAFÍA................................................................................................................................
110
José Luis Pedrosa Montes
VII
Pasarela X25­IP
GLOSARIO.............................................................................................................................
...........111
ANEXO A CONECTORES X25...............................................................................................
........116
ANEXO B CODIGOS X25...............................................................................................................
118
José Luis Pedrosa Montes
VIII
Pasarela X25­IP
0 AnSiB Net Solutions
AnSiB Net Solutions SL, es un empresa que nace a finales del año 2003 como Consultora orientada a servicios, productos y proyectos tecnológicos.
En muy poco tiempo se desarrolla ampliamente en el ámbito de la tecnología, prestando sus servicios de telecomunicaciones y desarrollo tanto a grandes multinacionales como a la Banca, administraciones públicas y consultoría.
En la actualidad continúa su crecimiento en las distintas líneas de negocio a las que se dedica. Su expansión no sólo se centra en España, también en Europa y Latinoamérica.
Tiene un único objetivo, y es ser una compañía líder dentro del campo de servicios tecnológicos y desarrollo de productos y proyectos de calidad profesional, que satisfagan a nuestros clientes. El diálogo entre todos los implicados en el proyecto, cliente, empleados y compañía, es un principio a la hora de obtener un óptimo resultado.
Para AnSiB, la satisfacción y el éxito del cliente es su éxito y para alcanzarlo, se compromete a encontrar las mejores soluciones a través de unos profesionales muy capacitados e implicados en ello.
AnSiB, tiene un importante compromiso empresarial, pero no sólo con el cliente, también lo tiene con sus propios empleados y con la actividad que lleva a cabo:
Con el Cliente
Porque es el primer objetivo de la empresa, AnSiB, le aporta las mejores soluciones y le asegura el éxito del proyecto:
●
El éxito de nuestros clientes es el nuestro: alineamos objetivos (win-win)
●
Generar la confianza del cliente es el primer objetivo de cada proyecto
●
Modelo de Interlocutor Único: un gestor de cliente para satisfacer todas sus peticiones
Con los Empleados
La empresa tiene unos empleados formados, de calidad y con talento, que además
cuentan con el soporte y los recursos necesarios para llevar a cabo un trabajo efectivo. Y elabora un
diseño conjunto de cada plan de carrera para generar una relación a largo plazo: cada empleado
José Luis Pedrosa Montes
1
Pasarela X25­IP
tiene “su” proyecto laboral.
El buen trabajo se hace con buenas herramientas: formación adecuada, soporte técnico,
recursos. La cultura de AnSiB se retro-alimenta de los empleados que la componen.
Con la Actividad
La perfecta ejecución de la actividad es sin duda la meta de la empresa, consiguiendo
así la máxima satisfacción del cliente, dicho de otra manera la excelencia es nuestra meta: lo que no
está bien ejecutado, está inacabado. En un entorno cambiante, adaptarse al cambio es la norma:
avanzamos con la tecnología. La calidad la genera el empleado con talento que está capacitado,
tiene recursos, está satisfecho y tiene un proyecto laboral. La labor beneficiosa es siempre
proactiva: (3P) Previsión, Planificación y Prevención.
Misión, Visión y Valores de AnSiB
Misión
Ser una compañía líder dedicada a la prestación de servicios tecnológicos y el desarrollo de productos/ proyectos fundamentados en la excelencia profesional y la satisfacción de nuestros clientes.
Visión
Actuar en sus iniciativas tecnológicas alineando los intereses de todos los implicados, clientes, empleados y compañía, para obtener los mejores resultados en base al talento, el compromiso y la sinergia de las partes en un ecosistema equilibrado y productivo.
Valores
●
La satisfacción del cliente es la medida del éxito.
●
El compromiso en la búsqueda de las mejores soluciones.
●
El capital humano como principal activo de la compañía.
●
La ética del trabajo y del esfuerzo aplicada 360º.
●
La equidad y el diálogo como principios de relación entre las partes.
●
La flexibilidad en la búsqueda de las mejores soluciones para nuestros clientes.
La empresa acoge varias líneas de negocio que a continuación se describen:
●
Ansiva
Pasarela de comunicaciones para datáfonos/tpv’s multiprotocolo
José Luis Pedrosa Montes
2
Pasarela X25­IP
●
TransMit
Sistema transaccional de gestión de recargas para móviles
●
Consultoría
Sistemas y Redes
Plataformas y desarrollos SW
SQA: Aseguramiento de la calidad del SW
Seguridad informática
●
Desarrollo
Aplicaciones Llave en Mano en cliente­servidor (C++, .Net, Visual Studio, java)
Bajo entornos Windows, Unix, Linux
Subcontratación de recursos especializados Desarrollo Plataformas: Oracle, Vignette, CRM, ERP
● Formación
Cursos específicos
Planes y proyectos de formación
Outsourcing de sistemas
Arquitectura y Planes de sistemas
●
Mantenimiento y evolución de plataformas y sistemas
Diseño y configuración de CPDs
Redes y comunicaciones
● Outsourcing de aplicaciones
Mantenimiento y evolución de plataformas y aplicaciones existentes
Proyectos de desarrollo y mantenimiento asociado, tanto en cliente como externamente Calidad del Software (SQA)
Oficinas de Proyectos
José Luis Pedrosa Montes
3
Pasarela X25­IP
1 JUSTIFICACIÓN DEL PROYECTO
1.1 Justificación académica:
1. Profundizar en los conocimientos sobre Linux
2. Practicar los conocimientos sobre la comunicación entre aplicaciones
3. Profundizar en la teoría Cliente/Servidor
4. Utilización y estudio del lenguaje C++
5. Desarrollo de aplicaciones utilizando la plataformas de bajo nivel
1.2 Justificación económica:
1. Una mayor estabilidad implica una menor pérdida de transacciones.
2. Mayor seguridad al filtrar por NRI + CUD
3. Implementación del protocolo v4, con paquetes de confirmación simplificando las conciliaciones de facturación entre empresas.
4. Uso de hardware con soporte para back­up de X25 por RDSI
5. Mayor control sobre el estado y comportamiento de la pasarela (entorno web)
José Luis Pedrosa Montes
4
Pasarela X25­IP
2 PLANTEAMIENTO DEL PROYECTO
2.1 Organigrama de los componentes:
2.2 Descripción de los integrantes:
Director : Alejandro Besada Juez, es el responsable de dar las especificaciones técnicas, orientar al alumno en las decisiones tecnológicas así como de la marcha del proyecto. Como representante de la empresa en el proyecto, es el responsable de suministrar los equipos hardware y software necesarios para el desarrollo del proyecto.
Coordinador: David Contreras Bárcena, su misión consiste en realizar revisiones periódicas del estado del proyecto. Al final del proyecto deberá validarlo, y también actuará como el responsable en última instancia de la calificación final del proyecto, teniendo en cuenta las valoraciones del director. Es el responsable administrativo del proyecto.
Alumno: José Luis Pedrosa, es el responsable de la planificación del proyecto, bajo la supervisión del coordinador y el director. El alumno diseñara, programara e implantará la pasarela. Diseñara y ejecutará las pruebas de carga para la posterior validación por parte del director José Luis Pedrosa Montes
5
Pasarela X25­IP
2.3 Estimación:
A continuación se adjunta una tabla con la estimación de horas requeridas para la consecución del desarrollo.
Rol
Director
Coordinador
Alumno
Sep Oct Nov Dic Ene Feb Mar Abril May Jun
2
2
1
30
1
40
2
1
1
1 0
45 30
0
35
2
3
4
Horas
Tarifa
€
5
4
26
50
1300
1
2
2
3
30 40 45 50
4
45
15
390
Total:
45
25
675
9750
11725
2.4 Presupuesto:
Teniendo en cuenta las estimaciones sobre las horas requeridas para el desarrollo del proyecto, tomando unas tarifas estándar y el precio aproximado de un servidor de las características necesarias, se genera el siguiente presupuesto:
Personal
Concepto
Presupuesto Pasarela X25-IP
Cantidad
Precio/ud.
Horas Director
27
50
1350
Horas Coordinador
20
45
900
400
25
10000
Horas Alumno
Sub Total:
Equipos
Total €
12250
Instalación Línea X25
1
300
300
Alquiler Línea X25
9
100
900
Servidor Dell PowerEdge
1
1500
Sub Total:
1500
2700
José Luis Pedrosa Montes
6
Pasarela X25­IP
2.5 Elección Hardware:
Dado que los productos X25 no son muy abundantes en el mercado, no fue muy complicada la elección de la tarjeta a utilizar, se incluyen las dos tarjetas que se consideraron como opciones.
FarSync X25 T1U
●
50MHz AMD Am186­CH (FS6140, FS6240)
●
1 Mbyte zero wait state SRAM
●
Intelligent Universal bus mastering PCI card
●
Short card (height 107mm, length 167mm)
●
PCI­X compatible
●
PCI v2.2 compliant
●
X.21 (V.11, RS422) ­ 15 pin male D type
●
V.35 ­ MRAC­34 male 'brick' type
●
RS232C (V.24, X.21bis) ­ 25 pin male D type
●
RS530 ­ 25 pin male D type
●
G.703 and G.704 BNC / RJ45 with I/F converters
José Luis Pedrosa Montes
7
Pasarela X25­IP
EICON C91 V2
●
MCP850 protocol processor
●
512KB RAM ●
Bus Type: PCI 2.2 32bit / 66MHz (3V PCI­X compatible)
●
Plug and Play ●
One V.24 connector ●
One ISDN S/T interface
●
V.24 DB­25 • CCITT V.24 Signaling ●
CCITT V.28 Electrical
●
CCITT X.21bis Electrical and signaling
●
EIA RS­232­C Electrical and signaling
Los dos fabricantes ofrecían una garantía de 5 años, la tecnología X25 esta mas que desarrollada y establecida, ninguna de las dos tarjetas ofrecían diferencias tecnológicas significativas y ambas compañías tienen un gran prestigio en el hardware de comunicaciones.
El factor determinante que hizo decantarnos por la tarjeta de Eicon, fue el hecho de que era la única que tenía soporte para back­up por RDSI. Esta capacidad tiene que estar acompañada por la contratación de la línea X25 con soporte RDSI, servicio que sí ofrece Telefónica, único proveedor de X25 en España.
José Luis Pedrosa Montes
8
Pasarela X25­IP
2.6 Elección Software:
La empresa cliente para la que se desarrolla el proyecto, se halla en un proceso de transición hacia soluciones basadas en software libre, eso hace que la mejor opción como sistema operativo sea Linux.
El lenguaje idóneo para esta clase de procesos es C/C++:
Debido a la naturaleza del proyecto, una pasarela de comunicaciones, tiene mas similitud con un programa en tiempo real que a una aplicación de tratamiento de datos. Dentro de los lenguajes de alto nivel, C y su extensión C++, son los que permiten un acceso a funciones de bajo nivel como pueden ser los semáforos, herramienta que en Java ha sido ocultada por funciones de sincronización. Esta clase de aplicaciones tienen una íntima relación con las funciones que ofrece el sistema operativo, solo accesibles normalmente desde C. Su velocidad de ejecución así como una gran potencia para hacer procesos de bajo nivel como gestión de memoria operaciones a nivel de bit, acceso a registros, hacen de C el lenguaje ideal, no obstante se ha elegido C++ como lenguaje para el desarrollo ya que permite la creación de clases, facilitando el diseño así como su mantenibilidad. Como se explicó en el anterior apartado, uno de los principales motivos para la elección de la tarjeta Eicon fue su potente API para C.
Siguiendo esta misma filosofía basada en software libre para el interfaz web, se hará uso de la arquitectura LAMP:
Un servidor de paginas web (A), montado sobre Linux(L), dejando a elección de la empresa el usar la misma máquina o no para este fin, usando MySql(M) como motor de base de datos, y PHP(P) para la programación de los interfaces web.
Debido al aislamiento que tendrá la máquina de desarrollo, no será posible tener acceso físico a la misma salvo el día de la instalación, esto hace que no se pueda instalar el correspondiente IDE gráfico, por otro lado tampoco es posible desarrollar la aplicación en una estación de trabajo, puesto que las librerías del hardware no se instalan correctamente en un ordenador sin la tarjeta físicamente conectada. Todos estos factores hacen que la opción mas recomendable para la codificación de la pasarela sea a través de sesiones de terminal remoto (SSH) y el editor VIM. José Luis Pedrosa Montes
9
Pasarela X25­IP
2.7 Metodología de desarrollo:
La empresa AnSiB Net solutions esta especializada en sistemas transaccionales, siendo una parte fundamental del negocio las pasarelas, AnSiB ha desarrollado una gran variedad de pasarelas entre distintos protocolos así como interfaces hardware. La experiencia personal del alumno en esta empresa de la cual es empleado desde hace dos años, nos ha hecho descartar el uso de una metodología de desarrollo de software tradicional, como pueda ser la metodología en cascada.
A priori la estructura de la pasarela ya estaba decidida, pues es común con otros proyectos, no requiriendo un estudio detallado. La experiencia nos dice que en esta clase de proyectos, es óptimo utilizar una metodología en espiral, haciendo un prototipo inicial que contenga una estructura sólida y que pueda ser modificada con facilidad. Las funcionalidades necesarias para el correcto funcionamiento se añaden en sucesivas iteraciones, evolucionando el prototipo inicial. Normalmente este tipo de pasarelas, dependen en exceso del comportamiento de las diferentes API's que proporciona el fabricante, no obteniendo el comportamiento que se podría extraer de los documentos técnicos. En este caso debido al tipo de negocio, no se puede proporcionar el cliente software que ha de usar la pasarela, y los diferentes nodos que se conectan a través de IPX25D implementan el protocolo PRA de maneras mas o menos laxas, este comportamiento obliga en numerosas ocasiones a modificar el software, por lo que una vez mas la fase de diseño no habría echo una gran aportación.
Son muchos los motivos que hacen diferente un pasarela de una aplicación, de esta última se espera flexibilidad, una interfaz de usuario cómoda e intuitiva, facilidad de uso, consumo de la menor cantidad de recursos posibles. Sin embargo lo que se le exige a una pasarela es fundamentalmente:
Estabilidad: son procesos sin los cuales los sistemas transaccionales se paran, y por lo tanto el negocio en si. Suelen ser aplicaciones que no se detienen jamas salvo por actualizaciones de software o mantenimiento. La pasarela debe tener un tiempo de funcionamiento sin fallos del orden de meses, requisito que no suele ser necesario en aplicaciones cliente. Es muy importante la correcta gestión de la memoria que no genere ningún “Memory Leak” es decir, uso de memoria José Luis Pedrosa Montes
10
Pasarela X25­IP
dinámica que crece indefinidamente, haciendo que la aplicación se detenga después de algunos horas o días. Su comportamiento ante la misma entrada siempre debe ser la misma salida. Tiempo de respuesta: Para todo problema siempre hay diferentes soluciones, dentro de las adecuadas, unas son mas lentas que otras usando menos recursos, en las pasarelas esto no es así siempre que se pueda se ha de elegir la solución que genere un tiempo de respuesta mas bajo, aun teniendo una peor relación recursos/velocidad.
Es decir, la mayor parte del tiempo de desarrollo en esta clase de proyectos se emplea en optimización, muchas pequeñas modificaciones del comportamiento y corrección de errores en tiempo de ejecución. Una vez mas la experiencia en proyectos de este tipo en el que se usa metodología en espiral, es necesario tener un control absoluto sobre las diferentes versiones se han ido desarrollado en las diferentes fases.
Para conseguir este control se ha usado el sistema de identificadores usado en la empresa cliente, ya que el proyecto se desarrollará en sus instalaciones. No se usará ningún programa o control riguroso de gestión de la configuración debido al escaso tamaño del proyecto. Se usará una carpeta en red en la que se almacenaran las diferentes versiones así como un registro de cambios (Changelog.txt)
Todo elemento entregable, documental o ejecutable se ajustara a la siguiente nomenclatura:
●
Tres caracteres alfanúmeros con las iniciales del cliente del proyecto.
●
Tres caracteres numéricos con el orden correlativo del proyecto para este cliente, empezando en cero y aumentando de uno en uno.
Documentales:
●
Tres caracteres fijos con el valor DOC.
●
Tres caracteres con el tipo de documento, dentro de la siguiente lista:
○
ACT: Actas de reunión.
○
ISE: Informes de seguimiento
○
EVA: Evaluación
José Luis Pedrosa Montes
11
Pasarela X25­IP
●
Dos caracteres numéricos para indicar la versión, la primera versión será siempre la 1
●
Un punto “.”
●
Dos caracteres numéricos con la revisión del documento, empezando en 0
Software:
●
Tres caracteres fijos con el valor SOF.
●
Tres caracteres con el tipo de documento, dentro de la siguiente lista:
○
SRC: Fichero con código fuente.
○
BIN: Fichero ejecutable.
○
LIB: Fichero con librerías
○
SRI: Fichero con script
○
CNF: Ficheros de configuración
○
MAN: Ficheros de ayuda integrados en programa
○
MKC: Ficheros de compilación automatizada
○
PRJ: Ficheros de definición del proyecto en el IDE
●
Hasta un máximo de 8 caracteres describiendo el elemento, en proyectos con orientación a objetos se usará el nombre de clase
●
Dos caracteres numéricos para indicar la versión, la primera versión será siempre la 1
●
Un punto “.”
●
Dos caracteres numéricos con la revisión del objeto, empezando en 0
●
Un punto “.”
●
Dos caracteres numéricos con el parche del objeto, empezando en 0
José Luis Pedrosa Montes
12
Pasarela X25­IP
2.8 Programación temporal:
Para la finalización del proyecto, AnSiB no ha puesto inconvenientes en establecer como fecha para la finalización del proyecto el fin del año lectivo, se ha dado como plazo hasta el mes de Junio. Se adjunta un diagrama con la planificación realizada: Se ha excluido la parte de pruebas del proyecto, ya que una vez desarrollado, y realizadas las
pruebas con el emulador, es necesario, ponerse en contacto con las diversas entidades que usa esta
pasarela e informarles de que será necesario que actualicen su software para implementar la versión
4 del protocolo, esto requiere un cierto tiempo de margen hasta que lo hayan desarrollado, una vez
los clientes estén listos comenzará la última parte de pruebas y refinamiento.
José Luis Pedrosa Montes
13
Pasarela X25­IP
3 ANÁLISIS DE REQUISITOS
José Luis Pedrosa Montes
14
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: X25IPD
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada Juez Estado: Aceptado
Pag: 1/10
Prioridad: Normal
Cliente: Identificador Requisito: R01
Tipo Requisito: Otros
Descripción Requisito: Todas las partes software utilizado ha de ser GNU
Beneficios: Acceso al código fuente de todas las partes del sistema.
Capacidad de depuración de problemas
Modificación del comportamiento
Comentarios / Soluciones requeridas:
Documentos relacionados:
GNU license
Requisitos relacionados: José Luis Pedrosa Montes
15
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada Juez
Estado: Pag: 2/10
Prioridad: Critica
Cliente: Identificador Requisito: R02
Tipo Requisito: Otros
Descripción Requisito: Registro de transacciones en fichero
Beneficios: Posibilidad de seguir las transacciones a lo largo del sistema transaccional.
Resolver posibles incidencias de facturación.
Comentarios / Soluciones requeridas:
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
16
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada
Estado: Aceptado
Pag: 3/10
Prioridad: Baja / Opcional
Cliente: Identificador Requisito: R03
Tipo Requisito: Funcional
Descripción Requisito: Registro en syslog
Beneficios: Syslog permite la redirección automática de ficheros, permitiendo así un copia de seguridad constante
Comentarios / Soluciones requeridas:
Se trata de un complemento a añadir no un requisito.
Documentos relacionados:
Requisitos relacionados: Es complementario a R02
José Luis Pedrosa Montes
17
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto: Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada Juez
Estado: Aceptado
Pag: 4/10
Prioridad: Alta
Cliente: Identificador Requisito: R04
Tipo Requisito: Otros
Descripción Requisito: Back Up RDSI de X25
Beneficios: El sistema transaccional no se detiene ante una incidencia de comunicaciones
Comentarios / Soluciones requeridas:
Elección del Hardware adecuado que soporte este tipo de back­up
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
18
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto: Alejandro Besada
Versión: 1.0
Fuente: Alejando Besada Juez
Estado: Pag: 5/10
Prioridad: Alta
Cliente: Identificador Requisito: R05
Tipo Requisito: Funcional
Descripción Requisito: Control de acceso
Beneficios: Evitar accesos indebidos
Comentarios / Soluciones requeridas:
Se ha de filtrar las llamadas X25 por RNI+CUD
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
19
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto: Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada Juez
Estado: Pag: 6/10
Prioridad: Alta
Cliente: Identificador Requisito: R06
Tipo Requisito: Funcional
Descripción Requisito: Herramienta monitorización y control multiplataforma
Beneficios: Capacidad para parar y arrancar la pasarela de manera remota.
Información sobre el estado y transacciones cursadas
Comentarios / Soluciones requeridas:
Diseñar una página web que ofrezca estas funcionalidades, usando ssh para el control, y MySql
para las estadísticas
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
20
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada
estado: Aceptado
Pag: 7/10
Prioridad: Media
Cliente:
Identificador Requisito: R07
Tipo Requisito: Funcional
Descripción Requisito: Cambio de tablas de rutas y/o control de acceso sin reinicio
Beneficios: Dar de alta nuevos clientes, o cambiar su servidor de manera dinámica
Comentarios / Soluciones requeridas:
Al ser un proceso demonio, no es posible interactuar con el de una manera habitual, sera necesario usar IPC y señales.
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
21
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Alejandro Besada Juez Estado: Aceptado
Pag: 8/10
Prioridad: Alta
Cliente: Identificador Requisito: R08
Tipo Requisito: Funcional
Descripción Requisito: Modos de funcionamiento: único, secuencial y concurrente
Beneficios: No es necesario forzar a los clientes a un protocolo rígido.
Mayor aprovechamiento de las lineas X25 al soportar concurrencia.
Comentarios / Soluciones requeridas:
Las entidades que realicen conexiones operan de tres maneras diferentes:
Único: Llamada, petición, respuesta y liberación del circuito
Secuencial: Llamada, petición, respuesta, petición, respuesta.... liberación del circuito.
Concurrente: Llamada, varias peticiones en vuelo, respuesta/s.... liberación del circuito.
Documentos relacionados:
Requisitos relacionados: José Luis Pedrosa Montes
22
Pasarela X25­IP
HOJA DE REQUISITOS
Proyecto: IPX25D
Fecha: Jefe proyecto:Alejandro Besada
Versión: 1.0
Fuente: Estado: Aceptado
Pag: 9/10
Prioridad: Alta
Cliente:
Identificador Requisito: R09
Tipo Requisito: Funcional
Descripción Requisito: Soporte protocolo PRA v.1 hasta v.4
Beneficios: Comentarios / Soluciones requeridas:
Documentos relacionados:
Especificaciones Protocolo PRA v.4, se adjunta a continuación Requisitos relacionados: José Luis Pedrosa Montes
23
Pasarela X25­IP
4 PROTOCOLO PRA V.4
José Luis Pedrosa Montes
24
Pasarela X25­IP
4.1 Introducción
El objeto del presente protocolo es servir de pasarela entre entidades externas y el servicio de recarga electrónica. Actualmente la conexión a través de esta pasarela se puede realizar vía IP o X25.
Las conexiones IP se establecen a través de líneas punto a punto o bien vía VPN y la conexión X25 se realiza a una línea asignada, de esta forma se ofrecen varios servicios de recarga electrónica:
Online, se envían los datos de la petición al operador final, que valida y ejecuta la operación. El servicio Online comprende las siguientes transacciones, dependiendo del operador:
•
Recargas.
•
Anulaciones.
•
Consultas.
Offline, se proporciona un código que el cliente final debe usar siguiendo las instrucciones de cada operador. Finalmente el operador ejecuta y valida la operación. No admite devolución. El servicio Offline comprende las siguientes transacciones:
•
Recargas.
•
Consultas.
Tarjeta, el cliente proporciona una tarjeta de recarga. Los datos de la tarjeta y de la recarga se envían al operador final, que valida y ejecuta la operación. Incluye los dos tipos de servicio anteriores, las transacciones pueden ser recargas y consultas pero las anulaciones solo se pueden hacer si están permitidas por el operador de la tarjeta.
La entidad externa realiza las anteriores operaciones enviando tramas en el formato definido por este protocolo.
José Luis Pedrosa Montes
25
Pasarela X25­IP
4.2 Descripción del protocolo:
En las operaciones de recarga correctas es imprescindible enviar una trama de confirmación para asegurar que el terminal recibió correctamente la respuesta. Cuando en una recarga se devuelve un error, no es necesario confirmar la recepción de dicho error.
Con cada petición de recarga se envía información sobre el resultado de la recarga anterior en el campo resultado previo (cabecera). Ante cualquier error que se genere en el terminal una vez enviada la confirmación se debe informar a través de este campo de dicho error. De esta forma se registra impresiones erróneas de tickets, desconexiones de corriente y cualquier otro tipo de error accidental que no permita la visualización de la información de la recarga.
Recarga offline (resultado previo = ‘00’):
TERMINAL
ENTIDAD EXTERNA
HOST
(1)RCG
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
REF
CONF
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
Recarga online (resultado previo = ‘01’):
TERMINAL
ENTIDAD EXTERNA
HOST
José Luis Pedrosa Montes
26
Pasarela X25­IP
(2)RCG
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
Registra error
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
REF
CONF
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
Cuando se recibe un código de error (NAK) no es necesario el envío de la trama de confirmación:
Recarga errónea:
TERMINAL
ENTIDAD EXTERNA
HOST
RCG
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
NAK
Tampoco es necesario el envío de la trama de confirmación para las transacciones de devolución (ANL), consulta (EST) y fin de día (FIN):
Devolución:
TERMINAL
ENTIDAD EXTERNA
HOST
ANL
­­­­­­­­­­­­­­>
­­­­­­­­­­­­­­>
José Luis Pedrosa Montes
27
Pasarela X25­IP
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
RAL
Consulta:
TERMINAL
ENTIDAD EXTERNA
HOST
EST
­­­­­­­­­­­­­­>
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
REN
Fin de día:
TERMINAL
ENTIDAD EXTERNA
HOST
FIN
­­­­­­­­­­­­­­>
<­­­­­­­­­­­­­­
<­­­­­­­­­­­­­­
José Luis Pedrosa Montes
FIN
28
Pasarela X25­IP
4.3 Tramas del terminal al host
Pre­cabecera:
Todas las entidades externas que acceden vía IP deben llevar este campo. Para las conexiones X25 no es necesario enviar este campo.
Campo
LONGITUD
Descripción
Valor fijo “00”
F/V Formato Longitud
F Alfanumérico 2 (bytes)
La respuesta desde el host son 2 bytes cuya traducción de hexadecimal a decimal es la longitud de la trama. El primer byte indica si se sobrepasa la longitud de 255 caracteres y cuantas veces, por ejemplo:
0x03 0x37  3 55  (3*255)+55= 820 caracteres de longitud (cabecera +
cuerpo de la trama)
0x00 0x63  0 99  0+99= 99 caracteres de longitud (cabecera + cuerpo de
la trama)
Cabecera:
Permite al sistema de recargas de la entidad externa identificar cada transacción para poder entregar correctamente la respuestas.
El campo RESULTADO PREVIO confirma que la transacción anterior fue correcta, este valor va asociado al código de comercio y al código de terminal. Se debe enviar la información correcta para cada recarga.
Se adjunta una tabla describiendo cada uno de los campos de la trama, sus posibles valores y el tipo José Luis Pedrosa Montes
29
Pasarela X25­IP
de dato:
Campo
Versión
Dial Indicator
DAD
RESULTADO
PREVIO
REFERENCIA
CÓDIGO
MERCHANT
CÓDIGO
COMERCIO
CÓDIGO
TERMINAL
TSC
OPERADOR
IMPORTE
Descripción
F/V Formato
• Versión 04. Valor fijo
F
Numérico
“04”.
• Nº De reintentos
generados por el
F
terminal para esta
transacción. Solo aplica
sobre terminales RTB
• Nº telefónico marcado
para establecer
comunicación.
Confirma la transacción
anterior. Valores posibles:
• Recarga anterior
F
Numérico
correcta. Valor “00”.
• Recarga anterior
incorrecta. Valor “01”.
Valor incremental con
respecto a la transacción del F
terminal.
código de Merchant,
F
Numérico
Proporcionado por la entidad
Longitud
2
2
6
Proporcionado por Entidad
F
Numérico
8
Proporcionado por Entidad.
F
Numérico
8
SECUENCIA +TIME_STAMP. En
formato ‘YYYYMMDD
F
Numérico
HHMMSSMS’ + Modificador
GTM
Identifica el operador al que
se envía la recarga. Es
F Alfanumérico
proporcionado por Entidad
Identifica el producto
F
Numérico
asociado al operador.
20
4
8
Confirma la transacción anterior. Valores posibles:
Recarga anterior correcta, el terminal recibió la respuesta a la recarga (REF). Valor “00”. Recarga anterior incorrecta, el terminal no recibió la respuesta. Valor “01”.
José Luis Pedrosa Montes
30
Pasarela X25­IP
4.4 Mensaje de solicitud de recarga
Campo
Descripción
F/V Formato Longitud
PRELa misma que se envió en
CABECERA+CABECE
F Alfanumérico
64
la petición de recarga.
RA
código de operación
Separador
cantidad
Tipo de mensaje: RLOA
Espacio, usado para
F Alfanumérico
delimitar campo = '|' pipe
Importes definidos por el
operador. Se añaden dos
ceros por la derecha para
los decimales y se completa
la longitud del campo con F
Numérico
espacios por la derecha.
p.e.: “500
“,”15000
José Luis Pedrosa Montes
4
1
6
”
Espacio, usado para
delimitar campo = '<FS>'
Número de teléfono a
recargar.
De tratarse de una recarga
extranjera, se usara el nº
Número
del cliente en el país de
origen de la tarjeta
obviando códigos
internacionales
Espacio, usado para
Separador
delimitar campo = '<DLE>'
Sector al que pertenece
terminal de la entidad
Sector
recargadora, asignado por
convenio.
Espacio, usado para
Separador
delimitar campo = '<CR>'
Código de provincia, desde
donde se realiza la recarga,
código de provincia
ver tablas de
correspondencia entre
códigos y provincia
Separador
Espacio, usado para
Separador
F Alfanumérico
F Alfanumérico
F
Numérico
1
15
F Alfanumérico
1
F Alfanumérico
20
F Alfanumérico
1
F Alfanumérico
2
F Alfanumérico
1
31
Pasarela X25­IP
Campo
Referencia
Separador
Impuesto
Separador
Identificador de
Moneda
Trailer ó Cola
CheckSum
José Luis Pedrosa Montes
Descripción
F/V Formato Longitud
delimitar campo = '<LF>'
Referencia local de la
entidad externa. Este
campo debe ser único
F
Numérico
20
para cada operación de
recarga y controlado por
la entidad
Espacio, usado para
F Alfanumérico
1
delimitar campo = '#'
Valores posibles:
1: 16% (Península Y
Baleares)
2: 4% (Ceuta)
3: 3% (Melilla)
F
Numérico
1
4: 0% (Canarias)
Este valor se refiere al
emplazamiento físico desde
el cual se realizo la recarga,
no el de la empresa.
Espacio, usado para
F Alfanumérico.
1
delimitar campo = '*'
Consultar tabla de
correspondencia entre
F Hexadecimal
1
códigos y monedas, para la
zona euro valor A
Valor constante usado
como delimitador de trama, V Hexadecimal
4
Secuencia fija =FAAF
CheckSum de 2 bytes
V Hexadecimal
2
32
Pasarela X25­IP
4.5 Mensaje de solicitud de recarga por tarjeta
Similar a la petición de recarga normal. Se añaden los detalles de la tarjeta del operador.
Campo
Descripción
F/V Formato Longitud
PRELa misma que se envió en
CABECERA+CABECER
F Alfanumérico
64
la petición de recarga.
A
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '<LF>'
código
Tipo de mensaje: CLOA
F Alfanumérico
4
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '|' pipe
Importes definidos por el
operador. Se añaden dos
ceros por la derecha para
los decimales y se
cantidad
completa la longitud del
F
Numérico
5
campo con espacios por la
derecha.
Separador
tarjeta de recarga
p.e.: “500
“,”15000 ”
Espacio, usado para
delimitar campo = '<FS>'
La información
capturada de la pista 2
de la banda magnética
por el terminal:
• Número de tarjeta
• Carácter “=”
• Fecha de
caducidad
Espacio, usado para
delimitar campo = '<LS>'
Clave de la entidad
clave_cliente_operador
recargadora
Clave de la entidad
clave_cliente
externa, definida por esta
última.
Espacio, usado para
Separador
delimitar campo = '#'
Separador
José Luis Pedrosa Montes
F Alfanumérico
F
Numérico
1
50
F Alfanumérico
1
F Alfanumérico
20
F Alfanumérico
20
F Alfanumérico
1
33
Pasarela X25­IP
Campo
Descripción
F/V Formato Longitud
Código de provincia, desde
donde se realiza la recarga,
código de provincia
ver tablas de
F Alfanumérico
2
correspondencia entre
códigos-provincia
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '#'
Referencia local de la
Referencia
F
Numérico
20
entidad externa.
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '|' pipe
Valores posibles:
1: 16% (Península Y
Baleares)
2: 4% (Ceuta)
3: 3% (Melilla)
Impuesto
F
Numérico
1
4: 0% (Canarias)
Este valor se refiere al
emplazamiento físico desde
el cual se realizo la recarga,
no el de la empresa.
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '#'
Consultar tabla de
correspondencia entre
Identificador de Moneda
F Hexadecimal
1
códigos y monedas, para la
zona euro valor A
Valor constante usado
Trailer ó Cola
como delimitador de trama, V Hexadecimal
4
Secuencia fija =FAAF
CheckSum
CheckSum de 2 bytes
V Hexadecimal
2
José Luis Pedrosa Montes
34
Pasarela X25­IP
Mensaje de respuesta para una recarga correcta
Campo
Descripción
F/V Formato Longitud
PRELa misma que se envió en la
CABECERA+CAB
F Alfanumérico
64
petición de recarga.
ECERA
código
F Alfanumérico
4
Tipo de mensaje: REFL
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
• Offline, número de
referencia local enviada
por la entidad externa
Referencia
F Alfanumérico
20
(LOCAL_REF).
• Online: referencia del
operador.
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
• Offline:
CÓD. ADMIN. (Longitud 20)
CÓD. ACTIV. (Longitud 20)
Código
Se completan longitudes con
F Alfanumérico
40
espacios por la derecha.
• Online, se completa con
espacios.
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Texto
Mensajes.
V Alfanumérico
700
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Adicionalmente se informa a la
entidad recargadora en caso de
que haya insuficiencia de
crédito o este cerca de
crédito
F Alfanumérico
1
agitarse:
Limite Crédito. Posibles Valores:
1.- CRÉDITO BAJO.
2.- CREDITO SUFICIENTE.
Valor constante usado como
Trailer ó Cola
delimitador de trama,
V Hexadecimal
4
Secuencia fija =FAAF
CheckSum
CheckSum de 2 bytes
V Hexadecimal
2
José Luis Pedrosa Montes
35
Pasarela X25­IP
Mensaje de respuesta de recarga errónea:
Campo
Descripción
F/V Formato Longitud
PRELa misma que se envió en la
CABECERA+CABE
F Alfanumérico
64
petición de recarga.
CERA
CODIGO
F Alfanumérico
3
Tipo de mensaje: NOP
Espacio, usado para
Separador
F Alfanumérico
1
delimitar campo = '<FS>'
Códigos de error e
interpretación. Posibles
valores:
CODRESP
01 - Error en número de
teléfono.
02 - Operación no permitida
en tarjeta.
03 - Cantidad incorrecta.
04 - Error de aplicación.
05 - Error de protocolo.
06 – Tiempo sobrepasado.
07 - Otro error.
F
Numérico
2
F
F
Alfanumérico
Alfanumérico
1
40
V
Hexadecimal
4
V
Hexadecimal
2
Otros errores:
11 - La transacción ya
existe.
12 - CIF o SFID incorrecto.
13 - SFID bloqueado.
14 – Crédito entidad
agotado.
Separador
Texto
Trailer ó Cola
CheckSum
Espacio
Texto descriptivo del error.
Valor constante usado como
delimitador de trama,
Secuencia fija =FAAF
CheckSum de 2 bytes
José Luis Pedrosa Montes
36
Pasarela X25­IP
Trama de confirmación de recarga
La entidad externa confirma que ha recibido la trama de respuesta a la
recarga.
Campo
Descripción
F/V Formato Longitud
PRELa misma que se envió en la
CABECERA+CAB
F Alfanumérico
64
petición de recarga.
ECERA
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Valor constante usado como
Trailer ó Cola
delimitador de trama,
V Hexadecimal
4
Secuencia fija =FAAF
CheckSum
CheckSum de 2 bytes
V Hexadecimal
2
José Luis Pedrosa Montes
37
Pasarela X25­IP
4.6 Anulación
Las peticiones de anulación se realizan mediante la referencia local enviada por la entidad externa.
Campo
PRECABECERA+CAB
ECERA
Código
Separador
Referencia
Trailer ó Cola
CheckSum
Descripción
F/V
Formato
Longitud
La pre-cabecera recoge la
longitud y la cabecera
F
Alfanumérico
54
identifica la transacción.
F
Alfanumérico
4
Tipo de mensaje: DEVP
Espacio, usado para delimitar
F
Alfanumérico
1
campo = '<FS>'
Referencia local de la entidad
F
Numérico
20
externa.
Valor constante usado como
delimitador de trama,
V
Hexadecimal
4
Secuencia fija =FAAF
CheckSum de 2 bytes
V
Hexadecimal
2
Mensaje de respuesta a la anulación:
Campo
Descripción
F/V
Formato Longitud
PRESe responden los mismos
CABECERA+CAB
F Alfanumérico
54
valores que se enviaron.
ECERA
Código
F Alfanumérico
3
Tipo de mensaje: DEVR
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Referencia local de la
Referencia
F Alfanumérico
20
recarga.
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Códigos de respuesta e
interpretación. Posibles
Código Respuestavalores:
F
Numérico
5
Se especifican mas adelante
los posibles valores
Espacio, usado para delimitar
Separador
F Alfanumérico
1
campo = '<FS>'
Texto
Texto descriptivo de error.
F Alfanumérico
40
Valor constante usado como
Trailer ó Cola
delimitador de trama,
V Hexadecimal
4
Secuencia fija =FAAF
CheckSum
CheckSum de 2 bytes
V Hexadecimal
2
José Luis Pedrosa Montes
38
Pasarela X25­IP
4.7 Consulta
A continuación se describe las tramas de consulta y sus respuestas
Mensaje de consulta:
Campo
Descripción
F/V Formato Longitud
PRELa pre-cabecera recoge la
Alfanuméric
CABECERA+CAB
longitud y la cabecera
F
54
o
ECERA
identifica la transacción.
Alfanuméric
Código
F
3
Tipo de mensaje: EST
o
Espacio, usado para delimitar
Alfanuméric
Separador
F
1
campo = '<FS>'
o
Referencia local de la entidad
Referencia
F Numérico
20
externa.
Valor constante usado como
Hexadecima
Trailer ó Cola
delimitador de trama,
V
4
l
Secuencia fija =FAAF
Hexadecima
CheckSum
CheckSum de 2 bytes
V
2
l
Mensaje de respuesta a la consulta:
Campo
PRECABECERA+CAB
ECERA
Código
Descripción
Se responden los mismos
valores que se enviaron.
Tipo de mensaje: REN
Espacio, usado para delimitar
Separador
campo = '<FS>'
Offline, referencia
Online, referencia del
Referencia
operador. Se completa con
espacios a la derecha.
Código RespuestaCódigos de respuesta e
interpretación. Posibles
valores:
José Luis Pedrosa Montes
F/V
Formato
Longitu
d
F Alfanumérico
54
F Alfanumérico
3
F Alfanumérico
1
F
F
Numérico
2
39
Pasarela X25­IP
Campo
Separador
Texto
Separador
Trailer ó Cola
CheckSum
José Luis Pedrosa Montes
Descripción
Se especifican mas adelante
los posibles valores
Espacio, usado para delimitar
campo = '<FS>'
Texto descriptivo de error.
Espacio, usado para delimitar
campo = '<FS>'
Valor constante usado como
delimitador de trama,
Secuencia fija =FAAF
CheckSum de 2 bytes
F/V
Formato
F Alfanumérico
Alfanumérico
Longitu
d
1
40
F Alfanumérico
1
F Hexadecimal
4
F Hexadecimal
2
40
Pasarela X25­IP
4.8 Resumen de códigos de respuestas
VENTAS
ACK ­ Transacción realizada.
NOP 01 – Identificador de Terminal incorrecto
NOP 02 – Clave cliente errónea
NOP 03 ­ Cantidad incorrecta.
NOP 04 ­ Error de aplicación.
NOP 05 ­ Error de protocolo.
NOP 06 – Trama mal formada
NOP 07 ­ Otro error.
NOP 08 – Impuesto no valido para provincia
NOP 11 ­ La transacción ya existe.
NOP 12 ­ CIF o SFID incorrecto.
NOP 14 – Clave operador errónea
NOP 15 ­ Operación no permitida en esta tarjeta.
NOP 16 – Operación rechazada
NOP 17 ­ Numero de teléfono no corresponde al operador.
NOP 18 – Error interno al servidor.
NOP 19 – Tiempo sobrepasado.
NOP 20 – Servicio no disponible temporalmente.
DEVOLUCIONES
DEV 00 ­ Devolución realizada.
DEV 01 – Transacción ya anulada.
DEV 02 ­ No se acepta la anulación (el crédito es inferior a la cantidad a anular).
CONSULTAS
CON 00 ­ Transacción realizada.
CON 02 ­ La transacción no existe.
CON 03 ­ Transacción en proceso.
José Luis Pedrosa Montes
41
Pasarela X25­IP
4.9 Tramas contables (fin de día)
El proceso contable de transacciones se realiza a través de una petición contable. Esta operación proporciona la información sobre las recargas realizadas por un terminal en el sistema. Se debe lanzar diariamente y es una operación de carácter informativo.
Devuelve la información ordenada por operador y tipo de recarga. La información final es el operador, el tipo de recarga, el número de recargas efectivas (aquellas sobre las que no se ha realizado una anulación) y el importe total de estas.
Para cerrar la información sobre las recargas realizadas, el terminal envía una trama que desencadena la generación de los totales de las recargas realizadas ordenadas por operador y tipo de operación.
Trama de petición.
Longitud
CABECERA
Versión
Resultado
previo
Usuario
Administrador
Código
comercio
Código
terminal
Fecha
Operador
Producto
Longitud de la trama
F
Alfanumérico.
2
Valor fijo: “04”
Solo utilizado para
recargas.
Se permite a la entidad,
asignar un usuario de
seguridad que sera
validado en la recepción
de la petición
Identifica el comercio
(Merchant).
Identifica el terminal
asociado al comercio.
‘ddmmaaaahhmmss’
Solo utilizado para
recargas, devoluciones y
consultas. Completar con
ceros por defecto.
F
Numérico
2
F
Numérico
2
F
Alfanumérico
F
Numérico
8
F
Alfanumérico
8
F
Numérico
17
F
Numérico
4
F
Numérico
8
Solo utilizado para
recargas, devoluciones y
consultas. Completar con
ceros por defecto.
José Luis Pedrosa Montes
42
Pasarela X25­IP
Longitud
CUERPO DE
LA TRAMA
Código
Separador
Trailer ó Cola
CheckSum
Longitud de la trama
F
Alfanumérico.
2
Identifica el tipo de
operación:
F
Alfanumérico
3
F
Alfanumérico
1
F
Hexadecimal
4
F
Hexadecimal
2
FDDI
Espacio, usado para
delimitar campo =
'<FS>'
Valor constante usado
como delimitador de
trama, Secuencia fija
=FAAF
CheckSum de 2 bytes
Respuesta petición correcta
En el caso de no haber recargas desde el último fin de día la trama de respuesta coincide con la de petición.
Campo
V/F
PRE-CABECERA
Descripción
Se responde la misma
cabecera que llega con la
petición.
Tipo de operación:
Código
FIN
Separador
Separador
Tipo de
operación
Separador
Operador 1
Separador
Espacio
Pipe (|)
off – Operación offline.
onl – Operación online.
Pipe (|)
Nombre del operador.
Pipe (|)
Número de recargas
efectivas.
Pipe (|)
Valor en euros del total de
recargas.
Valor constante usado
como delimitador de
trama, Secuencia fija
Recargas
Separador
Importe
Trailer ó Cola
José Luis Pedrosa Montes
Formato
Longitud
Alfanumérico
54
f
Alfanumérico
3
f
f
Alfanumérico
Alfanumérico
1
1
f
Alfanumérico
3
f
f
f
Alfanumérico
Alfanumérico
Alfanumérico
1
Variable
1
f
Numérico
Variable
f
Alfanumérico
1
f
Numérico
Variable
F
Hexadecimal
4
43
Pasarela X25­IP
Campo
Descripción
=FAAF
CheckSum de 2 bytes
CheckSum
V/F
Formato
Longitud
F
Hexadecimal
2
Respuesta petición incorrecta
Todos los valores de los campos son fijos.
Campo
PRECABECERA
CABECERA
CUERPO DE
LA TRAMA
Código
Descripción
Se responde la misma
cabecera que llega con la
petición.
V/F
Formato
Longitud
Alfanumérico
54
Alfanumérico
3
Espacio
Alfanumérico
1
Único valor posible “0”
Numérico
1
Espacio
“PETICIÓN INCORRECTA”
Valor constante usado
como delimitador de
trama, Secuencia fija
=FAAF
CheckSum de 2 bytes
Alfanumérico
Alfanumérico
1
19
F
Hexadecimal
4
F
Hexadecimal
2
Identifica el tipo de
operación que se realiza
en el sistema, valor:
FIN
Separador
Código de
respuesta
Separador
Mensaje
Trailer ó Cola
CheckSum
José Luis Pedrosa Montes
44
Pasarela X25­IP
5 DISEÑO DE LA PASARELA
José Luis Pedrosa Montes
45
Pasarela X25­IP
5.1 X25 y Api Eicon
X25 es un estándar UIT-T para redes de área amplia de conmutación de paquetes. Su
protocolo de enlace, LAPB, está basado en el protocolo HDLC proveniente de IBM. Establece
mecanismos de direccionamiento entre usuarios, negociación de características de comunicación y
técnicas de recuperación de errores. Los servicios públicos de conmutación de paquetes admiten
numerosos tipos de estaciones de distintos fabricantes. Por lo tanto, es de suma importancia definir
la interfaz entre el equipo del usuario final y la red.
La norma X25 es el estándar para redes de paquetes recomendado por CCITT, el cual
emitió el primer borrador en 1974. Este original sería revisado en 1976, en 1978 y en 1980, y de
nuevo en 1984, para dar lugar al texto definitivo publicado en 1985. El documento inicial incluía
una serie de propuestas sugeridas por Datapac, Telenet y Tymnet, tres nuevas redes de conmutación
de paquetes.
La X25 se define como la interfaz entre equipos terminales de datos y
equipos de terminación del circuito de datos para terminales que trabajan en modo paquete sobre
redes de datos públicas. Las redes utilizan la norma X25 para establecer los procedimientos
mediante los cuales dos ETD que trabajan en modo paquete se comunican a través de la red. Este
estándar pretende proporcionar procedimientos comunes de establecimiento de sesión e
intercambio de datos entre un ETD y una red de paquetes (ETCD). Entre estos procedimientos se
encuentran funciones como las siguientes: identificación de paquetes procedentes de ordenadores y
terminales concretos, asentimiento de paquetes, rechazo de paquetes, recuperación de errores y
control de flujo. Además, X25 proporciona algunas facilidades muy útiles, como por ejemplo en la
facturación a estaciones ETD distintas de la que genera el tráfico. Dentro de la perspectiva de X25,
una red opera en gran parte como un sistema telefónico. Una red X25 se asume como si estuviera
formada por complejos conmutadores de paquetes que tienen la capacidad necesaria para el
enrutamiento 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 línea de comunicación serial. En cierto sentido la comunicación entre
un anfitrión y un conmutador de paquetes X25 es una red miniatura que consiste en un enlace
serial. El anfitrión puede seguir un complicado procedimiento para transferir paquetes hacia la red.
El estándar X25 no incluye algoritmos de , pero conviene resaltar que, aunque los interfaces
ETD/ETCD de ambos extremos de la red son independientes uno de otro, X25 interviene desde un
José Luis Pedrosa Montes
46
Pasarela X25­IP
extremo hasta el otro, ya que el tráfico seleccionado se encamina desde el principio hasta el final. A
pesar de ello, el estándar recomendado es asimétrico ya que solo se define un lado de la interfaz
con la red(ETD/ETCD).
Ha sido la base para la implementación de varios protocolos. Entre los protocolos comúnmente asociados con el modelo OSI, el conjunto de protocolos conocido como X25 es probablemente el mejor conocido y el más ampliamente utilizado. X25 fue establecido como una recomendación de la ITU­TS (Telecommunications Section de la International Telecommunications Union), una organización internacional que recomienda estándares para los servicios telefónicos internacionales. X25 ha sido adoptado para las redes públicas de datos y es especialmente popular en Europa.
La recomendación X25 para el nivel de paquetes coincide con una de las recomendaciones del tercer nivel OSI. X25 abarca el tercer nivel y también los dos niveles más bajos. El interfaz de nivel físico recomendado entre el ETD y el ETCD es el X21. X25 asume que el nivel físico X21 mantiene activados los circuitos T(transmisión) y R(recepción) durante el intercambio de paquetes. Asume también, que el X21 se encuentra en estado 13S(enviar datos), 13R(recibir datos) o 13(transferencia de datos). Supone también que los canales C(control) e I(indicación) de X21 están activados. Por todo esto X25 utiliza el interfaz X21 que une el ETD y el ETCD como un "conducto de paquetes", en el cual los paquetes fluyen por las líneas de transmisión(T) y de recepción(R). El nivel físico de X25 no desempeña funciones de control significativas. Se trata más bien de un conducto pasivo, de cuyo control se encargan los niveles de enlace y de red.
En X25 se supone que el nivel de enlace es LAPB. Este protocolo de línea es un conjunto de HDLC. LAPB y X25 interactúan de la siguiente forma: En la trama LAPB, el paquete X25 se transporta dentro del campo I(información). Es LAPB el que se encarga de que lleguen correctamente los paquetes X25 que se transmiten a través de un canal susceptible de errores, desde o hacia la interfaz ETD/ETCD. La diferencia entre paquete y trama es que los paquetes se crean en el nivel de red y se insertan dentro de una trama, la cual se crea en nivel de enlace. Para funcionar bajo el entorno X25, LAPB José Luis Pedrosa Montes
47
Pasarela X25­IP
utiliza un subconjunto específico de HDLC. Los comandos que maneja son: ●
Información(I), ●
Receptor Preparado(RR), ●
Rechazo(REJ), ●
Receptor No Preparado(RNR), ●
Desconexión(DSC), ●
Activar Modo de Respuesta Asíncrono(SARM) ●
Activar Modo Asíncrono Equilibrado(SABM). Las respuestas utilizadas son las siguientes: Receptor Preparado(RR), Rechazo(REJ),
Receptor No Preparado(RNR), Asentimiento No Numerado(UA), Rechazo de Trama(FRMR) y
Desconectar Modo(DM). Los datos de usuario del campo I no pueden enviarse como respuesta. De
acuerdo con las reglas de direccionamiento HDLC, ello implica que las tramas I siempre
contendrán la dirección de destino con lo cual se evita toda posible ambigüedad en la interpretación
de la trama. X25 exige que LAPB utilice direcciones específicas dentro del nivel de enlace. Tanto
X25 como LAPB utilizan números de envió(S) y de recepción(R) para contabilizar el tráfico que
atraviesan sus respectivos niveles. En LAPB los números se denotan como N(S) y N(R), mientras
que en X25 la notación de los números de secuencia es P(S) y P(R).
A continuación adjunto un esquema en el que se puede ver de una manera gráfica la
relación X25 con la capa de protocolos OSI
José Luis Pedrosa Montes
48
Pasarela X25­IP
Por los motivos expuestos anteriormente se ha comprado una tarjeta X25 eicon C95 v.2. La API
proporcionada no es un estándar, por lo tanto requiere un estudio en detalle, ya que puede
condicionar el diseño de la pasarela, al desconocer las funcionalidades que implementa y a que
nivel.
La API en C para el uso de estas tarjetas, consta esencialmente de unos fichero de
cabeceras, en el que se definen los tipos de datos, así como los prototipos de las funciones, en el
momento del compilado, se enlaza la pasarela con las librerías, que son las encargadas de
relacionarse con el modulo del kernel (driver). Adjunto un diagrama explicativo:
José Luis Pedrosa Montes
49
Pasarela X25­IP
Al usar las librerías, se nos libera de todas las capas de protocolos inferiores, salvo
acceder a algunos bit característicos de niveles inferiores, no obstante, la arquitectura X25 no se
adapta al modelo IP al que estamos acostumbrados, apoyándonos directamente en TCP o UDP,
pudiendo tener cualquier protocolo en la capa de enlace/físico.
José Luis Pedrosa Montes
50
Pasarela X25­IP
5.2 Clases
Dentro de la lista de requisitos, es necesario tener en cuenta el numero 5 (R05 control
de acceso) a la hora de plantear la estructura del programa. Se nos indico que la pasarela ha de tener
control de acceso, pero ninguna de las versiones del protocolo PRA tiene en cuenta esta
funcionalidad, normalmente en X25 a tales efectos se usa un campo llamado Call User Data. Al
tratarse de una red de comunicación de paquetes exclusiva, junto con el hecho es con conexión, es
decir, hay un procedimiento de llamada, la hace muy segura, es decir, es como si se tratase de una
llamada módem a módem en un red TRC, la única manera de interceptar las comunicaciones es a
nivel físico, por todo esto, no se implementaran medidas de seguridad adicionales.
Cuando realizamos una llamada, se incluye un campo de como máximo 12 bytes, este es el CALL
USER DATA, CUD en adelante, la pasarela debe recoger ese campo y usarlo para validar el acceso,
así como decidir a que IP:PUERTO encaminarla.
A continuación se puede ver un paquete de llamada X25: José Luis Pedrosa Montes
51
Pasarela X25­IP
El campo CUD en detalle:
Si buscamos en la API, nos encontramos la siguiente función:
OSEXTERN OSINT OSFNDEF x25xlisten (
OSINT OSDTPTR cid,
OSINT waitmode,
OSINT port,
OSINT info,
struct x25data OSDTPTR facility,
struct x25data OSDTPTR udata,
char OSDTPTR remote,
char OSDTPTR local,
void (OSFNPTR post)(struct x25doneinfo *));
Esta función nos permite “escuchar” llamadas X25, antes de ser ejecutada, la variable local, debe estar inicializada con el NRI local en el que queremos escuchar, es instalaciones sencillas esto es simplemente en NRI de la linea en la que escuchamos, no obstante, no siempre es trivial, ya que es muy común el uso de extensiones (similares a las de una PBX), que puede ser indicadas en el proceso de marcado como un único numero. Las librerías esperan una cadena típica de C, es decir ASCII, con un '\0' al final de la cadena, también soportan el uso de caracteres comodines como '*' y '?'.
José Luis Pedrosa Montes
52
Pasarela X25­IP
La variable PORT, se usa para indicar la tarjeta que debe realizar esta acción, la numeración en Linux empieza en 1 y acaba en 48.
El campo CID, intenta imitar el comportamiento de file descriptor de Linux, cuando la llamada a esta función termina (sin errores) nos asigna un entero con el descriptor de la conexión, no obstante esto pese a intentar facilitar la programación, lleva a una confusión puesto que no es compatible con las funciones de Linux que soportan FILE DESCRIPTORS como pueda ser la función SELECT, en la cual puedes “interrogar” tantos FD's como se quiera, pudiendo ser de diferentes tipos, por ejemplo, un socket, y el descriptor de la entrada por consola. Lo cual nos lleva a analizar en detalle los modos de funcionamiento de las librerías, estos modos son elegidos mediante el campo WAITMODE, siendo desde un punto de vista lógico, síncrono y asíncrono: Si especificamos la macro X25NOWAIT, las llamadas a las funciones son asíncronas, es decir, simplemente manda la orden a las librerías y devuelve el control a la pasarela, siendo necesario llamar a x25done para comprobar el estado de la operación. En modo X25WAIT, tenemos el funcionamiento síncrono, es decir, la llamada a la función espera a que se complete (satisfactoriamente o no) y regresa al programa. Estos modos de funcionamiento pese a parecer un pequeño detalle a la hora de codificar la aplicación, resulta fundamental y determinante a la hora de elegir el diseño, este apartado se vera en detalle cuando se analicen en detalle el requisito R06.
El resto de parámetros de la función son asignados por la librería cuando se ha completado la llamada, el campo UDATA, es el que contendrá el contenido del campo CUD de la llamada recibida:
José Luis Pedrosa Montes
53
Pasarela X25­IP
Con el campo REMOTE, tendremos el NRI que generó la llamada, es importante señalar, que esta función no acepta las llamadas, simplemente nos notifica de ellas, siendo necesario, posteriormente llamar bien a X25XACEPT para aceptar la llamada o X25HANGUP para rechazarla, la analogía con IP es bastante explicita (listen y accept).
Teniendo en cuenta esto, una vez completada la función LISTEN, tenemos todos los datos que necesitábamos para aceptar una llamada o rechazarla y saber a que IP:PORT debería encaminarla. Ya que estos dos campos unidos, representan una “clave” es decir, siempre para un mismo NRI + CUD, siempre vamos a encaminarla hacia un mismo destino, puede ser usado como la clave de una tabla hash, en la que se almacenen las configuraciones de los destinos a encaminar.
Experiencias anteriores a este proyecto (otras pasarelas), recomiendan resolver una única vez, al inicio los nombres de maquina, guardar la dirección IP y usarla en futuras ocasiones ya convertida. Por esto al leer el fichero de configuración se resolverán y se guardaran en una estructura, que se puede ver en el fichero gateway.h:
typedef struct gwcnf
{
struct in_addr addr;
char nri[X25_ADDRLEN+X25_ADDREXT+2];
int port;
char cud[9];
José Luis Pedrosa Montes
54
Pasarela X25­IP
struct x25data udata;
char key[32];
}gwcnf;
Al leer el fichero, la llamada hostinfo=gethostbyname(ip), resuelve, para después
guardarlo en una gwcnf, addr.s_addr=((struct in_addr *)hostinfo->h_addr_list[0])->s_addr;
Como hash table se usara un Map de las librerías standart de C++, usando como clave
el propio valor KEY de la estructura, esto es mas conveniente que usar una clave externa a la
estructura, por que de esta manera, es mas sencilla la gestión de la memoria:
En un MAP de C++ no es sencillo trabajar con claves de tipo “(const) char *” que son
las adecuadas para este caso, ya que si al insertar un nuevo elemento con una variable de una
función local, al salir de esa función, ese puntero deja de tener el sentido que tenia en esa función,
ya que el stack no es el mismo, sin tener en cuenta de que si se añadiesen dos elementos a la hash
en una misma función solo tendría validez el último ya que el puntero seria el mismo.
La pasarela tiene la funcionalidad de recargar el fichero de configuración siempre que
se quiera, ejecutando “/etc/init.d/x25ipd reload” siendo necesario liberar toda la memoria usada, si
las claves fuesen externas a la estructura almacenada seria mas complejo.
Por todas estas razones se he definido la tabla hash de la siguiente manera:
struct strCmp
{
bool operator()( const char* s1, const char* s2 ) const
{
return (strcmp( s1, s2 ) < 0);
}
};
map
<const char*, gwcnf*, strCmp> gwtable;
Pese a ser una cantidad pequeña de memoria, evitamos un “memory leak” siempre desaconsejable.
José Luis Pedrosa Montes
55
Pasarela X25­IP
Los campos CUD y NRI no eran estrictamente necesarios, se han incluido para poder presentar mas
adecuadamente los datos en un registro de log.
Esta tabla hash se rellena durante el inicio del programa (o al ejecutar un reload), teniendo todos los
datos necesarios, para encontrar de manera eficiente las configuraciones. Buscar en un MAP
requiere mas lineas de lo que pudiera parecer intuitivamente, para mejorar la legibilidad del código,
se ha codificado la función: gwcnf *isValid(char *key), a la que se le pasa una clave de hash y
devuelve la estructura con la configuración asociada o NULLen el caso de no ser valida.
doService
X25CALL
HASH TABLE
NRI+CUD
GWCONFIG Manage
throwThread
En el diagrama se han nombrado las funciones que realizan cada paso, serán analizadas en
profundidad mas adelante.
Como se puede observar, la API de Eicon no es estándar, y podría dificultar el uso de
otro hardware X25 como puede ser las también excelentes FarSync, para facilitar el cambio en caso
de así considerarlo necesario, se ha creado una clase para representar la conexión.
Se han creado métodos de abstracción de todas las funciones, de manera que la pasarela en ningún
momento llama a funciones de los drivers de eicon, apoyándose en esta clase para todas las
José Luis Pedrosa Montes
56
Pasarela X25­IP
interacciones.
Sin tener acceso a las API's de otros fabricantes, se ha intentado ser lo mas genérico
posible, con una función Init, listen, accept, send y recv, también se han programado setters para
poder introducir variables de configuración por lo que es probable que si se decidiese el cambio,
bastaría con cambiar la clase interfaz de la línea y la pasarela funcionaría correctamente. Esta clase
se llama X25if, puede encontrase en X25interface.h y cpp, la cual se representa con el siguiente
diagrama de clase:
Es imprescindible llamar al método Init(), ya que es el que ejecuta X25Init(), llamada
que inicializa las librerías EICON.
SendData y getData, se comportan como los clásicos send y recv, pero se les ha
añadido la funcionalidad extra de poder esperar solo durante un cierto periodo de tiempo,
especificado en el valor de timeout.
Anterior mente he hecho referencia a que la pasarela ha de ser un demonio y el hecho de que es
complicado interactuar con el, a continuación voy a hacer un análisis en detalle de los porqués.
Un demonio, daemon ó dæmon es un tipo especial de proceso que se ejecuta en
segundo plano en vez de ser controlado directamente por el usuario (es un proceso no interactivo).
José Luis Pedrosa Montes
57
Pasarela X25­IP
Este tipo de programas se ejecutan de forma continua (infinita) , vale decir, que funciona sin tener
relación con una terminal o consola y, consecuentemente, sin interactuar con un humano.
En informática se utiliza el término daemon como abreviación de "Disk And Environment
MONitor" o monitor de entorno y disco, con el cual se hace referencia al software encargados de
administrador y controlar los servicios de red.
●
No disponen de una interfaz directa con un humano, ya sea gráfica o textual.
●
No hacen uso de la entradas y salidas estándar para comunicar errores o registrar su
funcionamiento, sino que usan archivos del sistema en zonas especiales (/var/log/ en los
UNIX más modernos) o utilizan otros demonios especializados en dicho registro como el
syslogd
Existen varios motivos para que este comportamiento sea así: seguridad, de esta manera nadie
puede interactuar con el, también hace que pueda ser cargado al inicio de sistema al entrar en el
RUNLEVEL que queramos, típicamente después de haber arrancado la red (3), de manera que se
comporta como un servicio de red. Se consiguen otras ventajas, por ejemplo que no pueda ser
arrancado dos veces, ya que al forzosamente ser lanzado desde “/etc/init.d” el script de lanzamiento
comprueba que exista otro proceso del mismo tipo, no obstante dado que ese es un paso
fundamental, el propio proceso establece un fichero de LOCK con el pid del proceso.
Durante el arranque, la pasarela debe realizar ciertas operaciones para convertirse en un demonio:
1. Comprobar que no existe el fichero de LOCK:
string fName=GetFileLockName();
if(access(fName.c_str(), F_OK)!=0)
2. Separarse de la SHELL que lo ejecuto, esto se consigue con un FORK
pid=fork();
3. Convertirse en el id de la sesión para no ser un proceso huérfano:
sid=setsid();
José Luis Pedrosa Montes
58
Pasarela X25­IP
4. Por motivos de seguridad cambiar el directorio de trabajo así como ajustar los permisos:
chdir("/");
umask(0);
5. Crear el fichero de LOCK.
Este comportamiento a la vez reviste un problema practico, como interactuar con un
proceso que ha sido diseñado para que sea hermético. Se ha encontrado un equilibrio entre
totalmente hermético e interactivo.
El proceso una vez arrancado escucha ciertas señales (SIGNAL), estas señales pueden
ser enviadas desde una consola con el mandato kill o bien otro proceso.
Se puede ver en las siguientes líneas de código:
void handler(int sig_number)
{switch (sig_number)
{
case SIGUSR2:
signalLog->doAppLog("Reloading configuration file... (user request)\n");
pthis->readConfiguration():
break;
default:
bRing=false;
break;
}
}struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler= &handler;
José Luis Pedrosa Montes
59
Pasarela X25­IP
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGUSR1, &sa, NULL);
sigaction(SIGUSR2, &sa, NULL);
Con estas líneas se define, cual tiene que ser la función que maneje las señales, y la propia función,
en la que se ve un switch que realiza el log adecuada para cada señal y la propia acción.
Toda la gestión del proceso, señales, lectura y parseo del fichero de configuración se ha hecho con
dos clases, para conseguir un código reutilizable, una clase con algunos métodos virtuales
(abstractos) que deben ser implementados por los que hereden de ella (Cdaemon) y la clase que la
hereda (daemongw) los diagramas de clase se adjuntan a continuación:
José Luis Pedrosa Montes
60
Pasarela X25­IP
Como se puede ver en el diagrama, los métodos RUN e INITDEMON, son virtuales y es Demongw
quien los implementa, esto es lógico puesto que es dependiente de cada proceso. Se ha creado un
método getTotalMemory, que accede al sistema virtual /proc y captura el uso de memoria, aparte
de motivos informativos, (se muestra al llamar a showStatus), es un dato importante a la hora de
saber si hay alguna fuga de memoria, ya que este proceso debe estar corriendo durante el mayor
tiempo posible (meses), y de haber algún problema quedaría plasmado pues se iría degradando el
uso de memoria, que crecería indefinidamente en lugar de mantenerse dentro de unas cotas tanto
inferior, como superior, es decir: se usa memoria dinámica durante la ejecución, cuanta mas carga
de trabajo, mas memoria consumirá, pero siempre dentro de unos limites, cosa que no ocurriría si
alguna parte de esa memoria no se liberase.
En algunos de estos métodos así como en funciones externas a la clase, se pueden observar variables del tipo puntero al mismo objeto, esto se debe a que las funciones que proporciona el sistema operativo, no admiten como argumentos métodos sino que tienen que recibir funciones externas a una clase, han de crearse métodos auxiliares dentro de la clase que llamen a funciones externas para que se puedan ejecutar las llamadas del sistema operativo, expongo un ejemplo:
Para el manejo de señales, como expuesto arriba, es necesario indicar que función debe ser llamada cuando llega una señal:
Crear una variable del tipo sigaction y limpiarla:
struct sigaction sa; memset(&sa, 0, sizeof(sa));
Asignar que función ha de ser llamada:
sa.sa_handler= &handler;
Notificar al sistema operativo:
sigaction(SIGTERM, &sa, NULL);
La función handler es externa a una clase, si pusiéramos un método de una clase con los tipos de José Luis Pedrosa Montes
61
Pasarela X25­IP
datos correctos:
void DemonPasarell::Demo(int sig)
{}
Indicamos que esta es la función:
sa.sa_handler= &DemonPasarell::Demo;
Al compilar nos encontramos con el siguiente error:
demongw.cpp:40: error: cannot convert ‘void (Demongw::*)(int)’ to ‘void (*)(int)’ in assignment
Error que tampoco es solucionable con casting, esos son los motivos de que algunos de los que deberían ser métodos de una clase, se hayan implementado como funciones. Pese a este inconveniente este modelo de procesos, cumple todos los requisitos de seguridad, y nos permite dar un cierto nº de ordenes a la pasarela, una de las cuales como se comento unas lineas antes es la de reload, funcionalidad que no fue especificada como requisito, pero durante el desarrollo del proyecto se considero muy recomendable, permitiéndonos cambiar “en caliente” las rutas sin necesidad de reiniciarla y tener que o bien echar a los clientes o bien esperar indefinidamente a que todos se vayan.
Para hacer esto posible, junto con el uso de señales el método READCONFIGURATION, en primer lugar comprueba la tabla hash actual, eliminando todos sus elementos así como liberando la memoria asociada a cada una de sus filas, para después parsear el fichero de configuración y llenar la tabla con los nuevos contenidos.
Para adaptarse al estilo de ficheros de configuración de demonios en Linux, se ha hecho uso de las librerías “iniParser: stand­alone ini Parser library in ANSI C”. El fichero de configuración será explicado en profundidad en el capítulo de instalación, simplemente expongo una parte para reflejar “estilo demonio Linux”
[GLOBAL]
localnri = "111111111111"; Nri en el que escucha la aplicación (obligatorio)
José Luis Pedrosa Montes
62
Pasarela X25­IP
syslog = yes; si la apliaccion debe hacer sislog
app_path = "/var/log/x25ipd/x25ipd.log"
trx_path = "/var/log/x25ipd/x25trx.log"
deb_path = "/var/log/x25ipd/x25deb.log"
[SECTOR/1]
nombre = "XXXXXXX"; nombre descriptivo para el sector
nri_cud1 = "1111111111:414E4453"; Nri+CUD del cual se aceptaran peticiones
ip_port1 = "10.42.4.110:1500"
Visto este fichero, considero conveniente explicar como se resolvió el requisito R02, el registro de transacciones en Log y syslog. La experiencia en el cliente para el que se desarrolla la pasarela nos dice que este punto es vital, ya que en numerosas ocasiones en necesario seguir el recorrido que hizo una determinada transacción. Se ha diseñado una clase de log, que puede manejar 3 ficheros diferentes simultáneamente. Expongo su diagrama de clase para poder explicarlo con mayor facilidad:
José Luis Pedrosa Montes
63
Pasarela X25­IP
Lo que mas llama la atención de esta clase es la variable singleton, acompaño una rápida explicación de singleton:
El patrón de diseño singleton (instancia única) está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella.
El patrón singleton se implementa creando en nuestra clase un método que crea una instancia del objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con atributos como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe todavía, sólo uno de ellos debe lograr crear el objeto. La solución clásica para este problema es utilizar exclusión mutua en el método de creación de la clase que implementa el patrón.
Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha clase controla el acceso a un recurso físico único (como puede ser el ratón o un archivo abierto en modo exclusivo) o cuando cierto tipo de datos debe estar disponible para todos los demás objetos de la aplicación.
El patrón singleton provee una única instancia global gracias a que:
•
La propia clase es responsable de crear la única instancia. •
Permite el acceso global a dicha instancia mediante un método de clase. •
Declara el constructor de clase como privado para que no sea instanciable directamente. Todavía no se ha explicado el apartado mas complejo de la pasarela que es en cuantas hebras debe estar separado el proceso, cuantas por cliente etc... aun así adelanto que se usarán mas de una, y es muy conveniente este tipo de patrón. Simplicidad de código, así como claridad son otros de las ventajas añadidas de usar este tipo de patrón, ya que si no fuese instanciable desde José Luis Pedrosa Montes
64
Pasarela X25­IP
cualquier parte del código sería necesario pasar una referencia del objeto a una gran cantidad de métodos, ya que gran partes del código necesitan dejar registro de las operaciones realizadas así como el resultado de las mismas.
Como el patrón indica los constructores son privados y solo pueden ser ejecutados desde dentro de la propia clase, para conseguir una referencia (puntero) a él, es necesario ejecutar el método getInstance(), que regula la creación del objeto. Al tratarse de un singleton y no ser accesible su constructor es necesario un método Init(), el cual abre los ficheros, antes se ha debido llamar a setXXXPath para indicarle la ruta del fichero.
Como se puede ver en el diagrama hay 3 ficheros de log, uno destinado a transacciones (doTrxLog), funcionamiento de la aplicación (doAppLog), y otro con fines de depuración (doDebLog), como se puede ver para el registro de transacciones se ha sobrecargado con uno y dos operadores, en uno de ellos simplemente se le pasa el mensaje a escribir, y en otro se le pasa además un identificador de transacción.
Debido al carácter multihilo de esta aplicación es necesario incorporar un semáforo para evitar que distintos hilos accedan al mismo fichero de manera recurrente. Solo se ha considerado oportuno añadirlo en el fichero de transacciones que es el que realmente esta expuesto a esta clase de colisiones. Esto nos asegura que las lineas del fichero de log sean consecuentes así como evitar posibles errores en el programa:
int logClass::doTrxLog(char *mes)
{
pthread_mutex_lock(&trxSem);
int res=­1;
if (transFd>0)
{
char charTime[100]="";
char logMes[5*1024]="";
time_t t;
José Luis Pedrosa Montes
65
Pasarela X25­IP
struct tm *sTM;
t=time(NULL);
sTM= localtime(&t);
strftime(charTime, 100, "%Y/%m/%d %H:%M:%S", sTM);
res=sprintf(logMes,"%s %s", charTime, mes);
res=write(transFd, logMes, res);
}
pthread_mutex_unlock(&trxSem);
return (res);
}
Como puede verse las operaciones que se realicen dentro de este método están aseguradas por trxSem, también se ha contado con la posibilidad de que algún fichero de texto no quiera ser usado y por lo tanto no se haya inicializado, y se comprueba el valor del descriptor del fichero, se devuelve el número de bytes escritos o ­1 en caso de error.
Una vez mas la experiencia en el cliente, y saber su manera de trabajar, nos ha hecho decidirnos por el uso de ficheros sin buffer intermedio (por defecto en tipos FILE*). Es muy usual en una empresa monitorizar el estado de un proceso o pasarela como en este caso mediante el comando “tail ­f FILENAME” el cual imprime el final del fichero, la opción ­f hace que sea de manera continua, si se usan ficheros con buffer, las escrituras se retardan hasta que el sistema operativo considera adecuado por rendimiento volcarlo, lo cual genera que el fichero sea mostrado a grandes saltos en lugar de secuencialmente línea a línea, para ello se abren los ficheros de la siguiente manera: transFd = open(transPath, O_WRONLY | O_APPEND | O_CREAT, S_IRWXU);
De un modo mas intuitivo: abre el fichero para escritura, creándolo si no existe, y posicionando el indicador al final del fichero (añadir).
A continuación se explica el diseño final de la parte software que hace realmente de pasarela, la clase gateway:
José Luis Pedrosa Montes
66
Pasarela X25­IP
Empezaré comentando la clase mas trivial, HUMANTEXT: como se ha podido ver en el documento que describe el protocolo PRA, contiene caracteres no imprimibles como puede ser el código ASCII 28 (decimal), esta función convierte el buffer enviado y reemplaza esos caracteres por una representación de su valor, por ejemplo el mencionado 28 se substituiría por cuatro caracteres: “<FS>”. Esto hace que los ficheros de registro de transacciones sean mucho mas legibles y se detecten problemas con mayor rapidez.
Como en todo demonio hay una función en la que el programa esta perpetuamente, normalmente en un bucle del tipo “while(true)”, en el caso de X25ipd esta función, es DOSERVICE(). En este caso no se ha usado un “while(true)”, ya que se desea poder parar la aplicación, al tratarse de transacciones, no es factible matar el proceso, se requiere una salida ordenada, para conseguir tal efecto se ha escogido la siguiente solución:
while(bRing)
{
José Luis Pedrosa Montes
67
Pasarela X25­IP
ESCUCHAR LLAMADAS X25 }
La variable bRing (boolean Running) es la que controla que el programa no termina, para cambiar el valor de esta variable se usa el método anteriormente explicado de capturas de señales, de manera que cuando llega una señal SIGKILL SIGSTOP, esa variable pasa a tomar valor FALSE y abandona el bucle principal, esperando a que las transacciones en vuelo acaben, pero no aceptando mas llamadas. Ahora paso a comentar como se ha satisfecho el requisito R08, los diferentes posibles modos de funcionamiento:
Los hosts PRA solo soportan una transacción por cada conexión TCP, a simple vista pudiera parecer trivial, pero hace que la pasarela tenga que llevar una lógica del contenido de las transacciones, ya que tenemos que hacer corresponder una relación del tipo 1 (x25) a N (IP) para cada uno de los clientes que se conectan. Antes de continuar incorporo un gráfico explicativo:
Como se aprecia, por cada cliente X25 tenemos N conexiones TCP lo cual nos obliga a saber para cada paquete X25 que conexión TCP corresponde. Esto ibliga a analizar las tramas recibidas y por lo tanto el protocolo PRA: Mirando los diferentes campos de las tramas del protocolo, parece haber un campo muy prometedor para ser considerado como diferente para trama (clave) , llamado Terminal Identifier, José Luis Pedrosa Montes
68
Pasarela X25­IP
(TID en adelante). El equipo técnico del cliente nos informó que dependiendo del medio por el que se efectúen las transacciones, se usan Terminales Virtuales, de manera que toda una entidad usa un único terminal, obligándonos a descartar el TID como identificador de trama. Se consideró un segundo campo como clave el “TimeStamp + Nº de secuencia”, una vez mas los técnicos nos informaron de que ese campo no es necesariamente obligatorio y simplemente esta destinado para ayudar a los clientes a gestionar sus transacciones, y de hecho muchos de ellos lo rellenan con ceros. El mismo equipo técnico nos resolvió este problema indicándonos que la cabecera entera de la trama es lo único que identifica una transacción unívocamente, permaneciendo constante durante todo su recorrido: peticiones, respuestas y confirmaciones.
Esto significa que por cada trama X25 se ha de buscar la transacción a la que pertenece y por lo tanto su conexión TCP asociada, y en caso de no existir crear una nueva. De manera análoga a como se hizo con las llamadas (NRI y CUD) y encontrar su configuración IP asociada, he considerado idóneo el uso de una tabla hash, en la que el campo clave es la cabecera de la transacción y el elemento asociado es un objeto del tipo transacción que se crea a tales efectos. Antes de proseguir con el estudio del diseño, describo someramente la clase Transacción. José Luis Pedrosa Montes
69
Pasarela X25­IP
En primer lugar y para corregir posibles perdidas de paquetes o conexión, se ha incluido un time stamp (starttm struct timeval), que se marca con la hora del sistema al ejecutar la el método START(). A través del método setSockFd(), guardamos el handler o descriptor de fichero de la conexión asociada a esa transacción. Complementario a este método es HASEXPIRED(), que comprueba la fecha inicial con la actual y nos devuelve un true o false en función de si esa diferencia alcanza el tiempo de timeout.
A modo informativo, tiene diversos métodos para obtener los diferentes campos de la trama: GUESSOPERATION, GUESSVERSION, a ambos se les pasa como argumento el buffer leído, guardando en las variables internas al objeto los valores apropiados. Una vez mas se ha incluido el campo clave de la hash dentro de la clase, por los mismos motivos que se explicaron en el caso de las configuraciones IP, los métodos GETKEY y SETKEY son la interfaz para acceder a esas variables.
Dado que una transacción tiene siempre un FD asociado,he considerado oportuno codificar los métodos SENDATA Y RECVDATA, comportándose de una manera análoga a send y recv entandar de sockets.
El protocolo nos indica que hay ciertas transacciones que requieren confirmación y otras no, información necesaria para eliminar y cerrar transacciones, al llamar a los métodos GUESSOPERATION y GUESSVERSION, automáticamente el objeto determina si necesita o no confirmación esa transacción en concreto. Una vez con estos puntos claros, se puede comenzar a hacer un estudio de las diferentes posibilidades estructurales que se contemplaron y por que se eligió una frente a las otras.
Modelo 1: Secuencial monohilo, tiene grandes inconvenientes, el mas determinante es los retardos que introduce en el sistema en condiciones de bajo uso, ya que se ha de esperar secuencialmente a mensajes X25 y después IP. Para descartar este modelo, es imperativo indicar la manera de funcionar de las librerías Eicon. Al no tratarse de FD's entandar no se les puede interrogar con un select, que genera una muy buena relación entre carga de CPU y tiempo de respuestas, desde un punto de vista conceptual, esta función actúa como un polling de eventos. Eicon no proporciona una herramienta similar, simplemente nos da dos opciones, modo síncrono José Luis Pedrosa Montes
70
Pasarela X25­IP
X25WAIT y asíncrono X25NOWAIT, si usásemos el modo X25WAIT nos quedaríamos indefinidamente esperando mensajes, y en el caso de trabajar con varias transacciones simultaneas, se daría el caso de que deberíamos estar escuchando IP y sin embargo la función estar “estancada” en X25 provocando la perdida de transacciones, también es importante tener en cuenta que en ocasiones, si se produce un error y nos encontramos recibiendo, puede ser que la función no regrese jamas dejando los recursos muertos, este comportamiento es bastante poco frecuente, pero ocurre, y es importante tenerlo en cuenta en aplicaciones que no pueden reiniciarse y deber tener un uptime muy largo. En la página siguiente se muestra el esquema lógico:
José Luis Pedrosa Montes
71
Pasarela X25­IP
Modelo 2: Doble hilo: Este modelo (el finalmente escogido), se compone de dos hilos, uno de ellos se encarga del lado X25 y otro del lado IP así como de la lógica transaccional. Este modelo tiene un claro problema, la comunicación entre procesos, como intercambiar lo recibido a través de hilo X25 para ser enviado por el hilo.
Para conseguir esto, se ha creado una clase especial, llamada mtbuffer (multi thread safe buffer), un buffer orientado a linea protegido con semáforos, no trata la memoria como un continuo, sino como un conjunto de lineas, declarando una matriz no un array, esto es especialmente útil, para determinar que mensaje corresponde a cada transacción. Adjunto un esquema antes de seguir explicándolo:
Este esquema se reproducirá tantas veces como llamadas X25 concurrentes.
Como se puede observar la función (método) que se encarga de la conexión X25 se llama X25SIDE, la cual simplemente cicla entre recibir a través de la linea para escribir en el buffer de recepción y leer del buffer de envío para enviarlo al cliente.
Es la función encargada del lado IP quien además de enviar y recibir (bufferA­>IP, IP­>bufferB) se encarga de la gestión de la lógica de las transacciones, haciendo uso de los métodos proporcionados por la clase transacción. Son muchas las ventajas de este diseño, la “lógica de negocio” se traslada a la clase transacción, y basta con cambiar esa clase para implementar otro protocolo distinto, así mismo se reducen considerablemente los tiempos muertos en los que pudiera haber paquetes José Luis Pedrosa Montes
72
Pasarela X25­IP
esperando a ser recibidos o enviados, ya que hay un hilo para cada interfaz. Para las conexiones TCP se utilizara la función SELECT, permite añadir un número N de sockets y dormir el proceso durante un tiempo Y hasta que al menos uno de ellos tiene datos o expira el contador.
Esta clase no requiere mayor explicación salvo indicar que esta protegida con semáforos, de manera que es adecuada usarla en entornos multi­proceso. Simplemente indicar que es necesario pasarle como argumento la variable en la que queremos que nos deje la linea leída, devuelve el numero de bytes copiados o ­1 en caso de error. ISEMPTY nos devuelve un bool indicándonos si la pila de “mensajes” esta llena o vacía.
Modelo 3: 4 hilos: Se consideró la opción de usar una arquitectura de 4 hilos por cliente:
Esta arquitectura se descartó puesto a que los sockets ip no son “Thread Safe”, y no pueden ser usados simultáneamente en dos hilos y si se limitase su uso mediante semáforos (evitando así la concurrencia) no aportarían ninguna ventaja (frente a dos hilos), complicando José Luis Pedrosa Montes
73
Pasarela X25­IP
código sin necesidad. De estas tres opciones, como se ha explicado anteriormente se escogió la de dos hilos, cada uno de ellos implementado en los métodos IPSIDE y X25SIDE, usando como “lanzadera de hilos” void *throwX25Thread(void *thrparam) y void *throwIpThread(void *thrparam).
En el diseño de la pasarela se tuvo que tomar la decisión sobre que mecanismo de paralelización usar, pthread o fork.
La operación de fork, realiza un duplicado exacto en memoria del proceso que efectúa esta llamada, de manera que tenemos dos procesos independientes:
FO
RK
()
Pthread_create, por el contrario, usa parte del stack del proceso que llama a pthread en forma de stack del nuevo hilo creado, habrá tantos “sub­stacks” en el proceso como threads se hallan llamado.
Estos son liberados en distintos momentos, dependiendo del tipo de modo de José Luis Pedrosa Montes
74
Pasarela X25­IP
funcionamiento elegido para el hilo. Si se marca el hilo como “attached”, el proceso solo se libera una vez se espera o comprueba el resultado de su ejecución con pthread_join. Si por el contrario el hilo es del tipo detached, ( pthread_detach), todos los recursos del hilo son liberados cuando el hilo finaliza. Es importante recalcar que si un hilo realiza un exit(), no termina el propio hilo sino toda la aplicación, para terminar un hilo es necesario usar pthread_exit() o bien return.
PT
HR
EA
D_
CR
EA
TE
()
De esta manera el proceso crece en tamaño, pero sigue siendo un único proceso, desde el punto de vista del sistema operativo. Los hilos creados por pthread, son denominados procesos ligeros, en contraposición con los creados a través de Fork. Al cambiar de un proceso a otro se ha proceder a lo que se conoce como cambio de contexto, como se sabe los sistemas operativos actuales, no ejecutan una única tarea, si no varias en paralelo (simulado por slots de tiempo), de esta manera, los cambios de contexto entre hilos del mismo proceso es mucho mas rápida que entre procesos independientes, lo que consigue una mejora notoria en el rendimiento de las aplicaciones. José Luis Pedrosa Montes
75
Pasarela X25­IP
A continuación se adjunta una tabla con un benchmark usando las dos opciones:
Este benchmark es simplemente un bucle que lanza operaciones de pthread o fork. Como se puede ver, el coste de realizar los fork es mucho mas costoso que el de pthread. El programa de demo simplemente hace un sleep en cada uno de los hilos, por lo que tampoco queda reflejado lo que beneficia a los cambios de contexto entre procesos. Aun así es suficiente para dejar claro que pthread es la mejor opción a utilizar.
Esta es la clase que realmente realiza el trabajo de pasarela, por cada cliente se creara una nueva instancia. A manera de recapitulación, se ha realizado un diagrama UML con todas las clases codificadas para que se pueda ver la aplicación de una manera mas general:
José Luis Pedrosa Montes
76
Pasarela X25­IP
José Luis Pedrosa Montes
77
Pasarela X25­IP
5.3 Aplicación Web
Con este diseño, la pasarela se cumplen satisfactoriamente todos los requisitos excepto
una interfaz de control y monitorización, para ello se utilizará una interfaz web, que resuma las
transacciones realizadas, y permita operaciones de control.
Se utilizara una base de datos en la que se guarde registro de cada transacción
procesada, datos a partir de los cuales la propia página generará los informes.
Como se ha explicado en este documento, el retardo es un factor fundamental, la
pasarela debe intentar retrasar el envío y recepción de paquetes lo menor posible, por otro lado cada
transacción ha de ser enviada a un servidor de Base de Datos (MySql), lo que introduce un retardo
en ciertas condiciones como pueda ser que la base de datos no este en la misma red que la pasarela,
situación que se producía en el cliente sucede.
La solución por la que se ha optado es por hacer inserciones diferidas en la base de
datos, se ha creado una clase especial para soportar este comportamiento. Una cola de “querys” que
va siendo procesada por un hilo independiente a los hilos de los clientes, cada transacción
simplemente copia los datos de la “query” en memoria para ser procesada por el hilo.
Este diseño aporta mas ventajas a parte de eliminar los retardos (o reducirlos drásticamente):
●
Protección ante caídas del gestor de base de datos, ya que esa cola se ha dimensionado para
que soporte (estadísticamente) una caída de aproximadamente 10 minutos, si pasado ese
tiempo no se recuperase la base de datos, las transacciones serian volcadas a fichero en
forma de archivo SQL para ser procesadas manualmente mas tarde.
●
Uso de una única conexión a base de datos, ya que la clase que la instancia que tendría la
conexión a la base de datos, seria única (el hilo independiente), así se hace una menor
sobrecarga del gestor, se obtiene un mejor uso del ancho de banda al eliminar todas las
conexiones de cada hilo.
●
Lógica de base de datos, ya que el hilo gestor, contiene la lógica de como responder ante
que tipo de fallos, por ejemplo datos incorrectos provenientes de errores en la transmisión,
o una caída de la linea, solo recolectando en los casos necesarios.
●
Protección ante errores de red o DNS, si el servidor de DNS o la red se cae, el intento de
José Luis Pedrosa Montes
78
Pasarela X25­IP
conectar puede tardar hasta dos minutos (tiempo máximo TCP), si ese caso sucede, no se
podría atender a ningún cliente, puesto que al primer acceso de base de datos el hilo
quedaría suspendido durante hasta dos minutos.
El diagrama UML se muestra a continuación: Como se puede ver hay un método init, que inicializa todas las variables y lanza el hilo
que gestiona la conexión, se han incluido un getUsage, que devuelve el porcentaje de la cola de
mensajes usada, getStatus que informa de si esta la conexión esta activa.
Cada hilo de los clientes al terminar una transacción, construyen la query y ejecutan el
método addQuerytoqueue, el cual lo copia a la cola, es importante recalcar que se trata de una copia
y no de la misma memoria, y que se puede reutilizar la misma variable, disminuyendo la
complejidad de la memoria dinámica, ya que los hilos pueden hacer uso de una variable local y no
tener que esperar a que se procese la query para liberarla.
José Luis Pedrosa Montes
79
Pasarela X25­IP
Con estos datos ya insertados en la base de datos la pagina es capaz de obtener
estadísticas y mostrar información sobre las transacciones, aun es necesario solucionar como se va
a tener control sobre la aplicación y el servidor de BBDD.
Es importante tener en cuenta que MySql no tiene por que estar necesariamente
instalado en una maquina Linux, por lo tanto las funciones deben ser independientes de las
plataforma.
Para poder controlar y monitorizar los servicios instalados en maquinas bajo Microsoft
Windows ha hecho uso de las librerías win32services de código libre para PHP. Estas librerías
aportan la funcionalidad necesaria para preguntar por el estado de un servicio, pararlo o arrancarlo.
Típicamente los servicios en Linux se arrancan o paran mediante scripts habilitados a
tal efecto en el directorio /etc/init.d/ por ejemplo “/etc/init.d/SERVICE start|stop|status”, esto
devuelve mensajes standart informando de si el servicio se encuentra en ejecución, o no. Para
poder acceder a un servidor Linux existen diversos tipos de conexiones, el mas usado:
SSH: es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a
máquinas remotas a través de una red. Permite manejar por completo el ordenador mediante un
intérprete de comandos. Este programa, permite interactuar con máquinas remotas, de manera
segura, cada nueva sesión, genera una nueva clave pública que se intercambian mediante cifrado
asimétrico, con esta clave, se hace cifrado simétrico para toda la conexión.
TSH: muy similar a SSH pero con medidas de seguridad no tan estrictas, tiene la ventaja de ser mas
rápido en la conexión que ssh.
Para usar ssh desde PHP tenemos dos opciones:
●
Uso de la función PHP ssh2, ssh2_exec ( resource session, string command [, string pty [,
array env [, int width [, int height [, int width_height_type]]]]] )
●
función exec passthru ( string comando [, int &var_retorno] ), incluyendo dentro la función
a ejecutar el propio mandato ssh
La función passthru es mas versátil, pero, resulta mas complicada de configurar, es
necesario
habilitar en el servidor permisos para permitir el acceso sin contraseña usando
certificados, lo que requiere generar certificados en cada cliente que se tenga que conectar.
José Luis Pedrosa Montes
80
Pasarela X25­IP
Si se quiere poder usar TSH por velocidad en lugar de SSH, es necesario usar passthru
ya que PHP no proporciona ninguna función para esta shell remota.
Este planteamiento se ha hecho teniendo en cuenta que se va a usar un servidor Linux
para generar estas páginas, ya que Windows no dispone de estas herramientas. No obstante es
posible instalarlos mediante Cygwin: entorno de emulación de Linux sobre Windows, se trata de
una DLL que proporciona la API de Linux, y un gran conjunto de herramientas, entre las que se
puede encontrar SSH y TSH.
Para soportar ambos sistemas simultáneamente se ha creado un archivo de funciones a
modo de “librería” llamado services.inc que puede ser incluido en cualquier script PHP. Estas
librerías consultan tablas mysql en las que se “registran” los servidores sobre los que se quiere
tener control (el diagrama de base de datos se incluye mas abajo), esencialmente esa tabla contiene
por cada fila, el sistema operativo (Linux o Windows), el nombre o ip del host, el nombre con el
que el servicio esta registrado en la máquina y a modo informativo un displayName que se usará
para mostrar un texto o nombre descriptivo del servicio. Por ejemplo, apache normalmente esta
registrado como httpd y en el nombre usamos Servidor Apache, de esta manera no es necesario
conocer el nombre exacto de cada servicio.
Las librerías proporcionan las siguientes funciones:
getTypes():
Por comodidad se ha añadido un campo type, para poder agrupar servidores, por ejemplo “x25gw”.
Esta función nos devuelve los diferentes tipos de servidores
getServicesOfType():
Dado un tipo de servidor nos devuelve todos los servidores del grupo.
stopService():
Se le pasa como argumento un servicio, y lo detiene.
startService():
Complementario a stopService()
getStatusOfService();
También recibe como argumento un servicio, al terminar esta función devuelve el estado del
José Luis Pedrosa Montes
81
Pasarela X25­IP
servicio, de acuerdo con las librerías win32services:
●
4: el servicio esta ejecutándose
●
1: el servicio esta detenido
●
0: el servicio no responde
printService():
Imprime el estado de un servicio, con las correspondientes imágenes, esta función se apoya en la
anterior.
Con
esta
librería tenemos acceso a
un
servicio
a
cualquier
maquina,
independientemente de la plataforma en la que este instalada.
Para la monitorización también se han creado otras librerías, que generan ficheros con
la información que necesita la página:
Siguiendo el estilo UNIX se ha tomado el patrón de 5, 10 y 15 minutos, por cada
cliente se muestra la cantidad de transacciones correctas durante esos tres periodos de tiempo.
Toda la información mencionada anteriormente es de gran utilidad, pero es necesaria
alguna herramienta que proporcione una información mas detallada, separando información por
cada uno de los servidores o tarjetas, para conseguir una información lo mas parecido a tiempo real,
se ha incluido un applet con gráficas con el numero de transacciones entrantes, correctas y los
diferentes tipos de error, los paquetes de JfreeChart son la herramienta perfecta para conseguir
unos gráficos interactivos.
Para conseguir que los datos se actualicen, se han incluido unas tareas periódicas en el
crontab que generan los ficheros para los applets. Se contempló la opción de que fuese las request
de los navegadores los que generaran las consultas a base de datos y los ficheros para los applets,
pero se estimo que las consultas eran demasiado pesadas como para se realizasen por cada uno de
los clientes conectados.
El cron es una utilidad derivada de UNIX, un administrador regular de procesos en
segundo plano (demonio) que ejecuta programas a intervalos regulares (por ejemplo, cada minuto,
día, semana o mes). Los procesos que deben ejecutarse y la hora en la que deben hacerlo se
José Luis Pedrosa Montes
82
Pasarela X25­IP
especifican en el archivo crontab.
Cron se podría definir como el "equivalente" a Tareas Programadas de Windows. Los
usuarios habilitados para crear su archivo crontab se especifican en el archivo cron.allow. De
manera análoga, los que no lo tienen permitido figuran en /etc/cron.d/cron.deny, o /etc/cron.deny,
dependiendo de la versión de Unix.
El momento de ejecución se específica de acuerdo con la siguiente tabla:
1. Minutos: (0-59)
2. Horas: (0-23)
3. Días: (1-31)
4. Mes: (1-12)
5. Día de la semana: (0-6), siendo 1=Lunes, 2=Martes, ... 6=sábado y 0=Domingo
Para especificar todos los valores posibles de una variable se utiliza un asterisco (*).
Por ejemplo:
30 10 * * 1 /usr/bin/who >> /home/quien.tex
Ejecuta la orden who todos los lunes a las 10:30 y guarda la salida en el archivo quien.tex
Con esta herramienta programamos una tarea para que genere los ficheros con la
frecuencia que queramos, se sugiere el valor de un minuto, es decir, todos los campos a *.
El comando a lanzar sera “$(PHP_HOME)/php $(X25IPD_HOME)/filetochar.php”
Este script en php lanza unas consultas a la base de datos preguntado por el numero de
transacciones en el último minuto, después contabiliza el numero total de peticiones recibidas, el
numero de correctas y el de erróneas.
La principal tabla dentro de MySql para la estadísticas se llama trx (transacciones),
cada una de las pasarelas introduce una fila por cada transacción. El código de error es el principal
indicador, en caso de que la transacción sea correcta, este campo toma el valor 0, se incluye la
configuración (NRI + CUD) de la que proviene esa transacción de esa manera se puede saber el
cliente que inició la transacción, estos dos campos, nos permites obtener unas estadísticas de el
José Luis Pedrosa Montes
83
Pasarela X25­IP
estado global de la pasarela sabiendo si se están produciendo demasiados errores, determinando si
se trata de un problema localizado de un cliente, o de toda la pasarela. Adicionalmente ayuda a
detectar problemas en las líneas X25 al dejar de ver transacciones bien correctas o incorrectas.
Para ayudar a determinar si se trata de un problema en una de las líneas o se trata de un
problema aislado, se ha integrado un applet usando JfreeChart que muestra en tiempo real el
numero de transacciones por minuto, mediante dos indicadores, translaciones correctas e
incorrectas.
Estas gráficas requieren que en cada una de las transacciones se registre el host donde
se ejecuta la pasarela, este campo se añadió a la tabla trx. Así mismo, para saber en que momento se
produce la transacción es necesario registrar la fecha con precisión de segundo. Durante la fase de
pruebas del proyecto, se detectó que era de gran utilidad disponer no solo de la fecha en la que se
realizó la transacción si no también saber la fecha en la que se realizó la inserción en la base de
datos.
Con los dos datos adicionalmente se puede determinar si a una hora determinada de un
día que no se registraron transacciones se debía a una caída de base de datos o a una incidencia de
alguna linea o problema en las pasarelas. también ayuda a detectar la caída ya que las gráficas al
levantarse el servicio de base de datos se incrementa repentinamente.
Para poder generar estos datos, se deben hacer consultas a la base de datos cada poco
tiempo, se estimo que tener los datos actualizados cada minuto ofrecía la funcionalidad adecuada.
Durante un periodo de un mes, se calcula que aproximadamente se registrarán uno o dos millones
de transacciones al mes, para agilizar el proceso de la obtención de datos se ha creado un índice
sobre la columna host y fecha.
Entrando en mas detalle, la linea del cron que guarda en archivos el numero de
transacciones realizadas para esto se realiza la siguiente query:
“ $query="SELECT localserver, count(*) as countTrx FROM trx where error='0' and
insert_date>=DATE_ADD(now(), INTERVAL -".$minutes." MINUTE) group by localserver;";”
Esta
query
se
ha
José Luis Pedrosa Montes
incluido
en
las
librerías
PHP
en
una
función
llamada
84
Pasarela X25­IP
getLastTRXByServer($minutes, $status). El primer argumento indica de cuantos minutos tiene que
ser el conteo, y status puede tener dos valores 'ok' y 'error', en el caso de error no se devuelve un
único dato sino una “matriz” en el que el primer campo es el código de error y en el segundo el nº
de esos errores para un servidor.
El resultado de estas querys se van almacenando en un fichero mediante un script que
se encuentra en la carpeta cron. Este script PHP se encarga de que solo haya un determinado
numero de lineas en el fichero de datos, ya que si no el Applet de java no se representa
correctamente ocupando mas pixeles de los destinados a el. Se generaran tantos ficheros de datos
como servidores corriendo el servicio de pasarela definidos en la tabla Servers y Services de la base
de datos.
José Luis Pedrosa Montes
85
Pasarela X25­IP
José Luis Pedrosa Montes
86
Pasarela X25­IP
Una vez que esta todo el sistema preparado, las pasarelas, el servidor MySql, el servidor apache con los módulos de PHP y win32services, estamos listos para usarlo, para ello basta con abrir un navegador e introducir la URL donde se haya hospedado:
El resultado es esta página:
Desde esta página se pueden ver el estado de cada servidor así como de los servicios, permitiendo ver la tasa de errores global. En la siguiente página explicaré en detalle cada uno de los cuadros que se presentan:
José Luis Pedrosa Montes
87
Pasarela X25­IP
El cuadro de control:
Este cuadro nos permite ver los diferentes servidores dados de alta en la base de datos, para poder interactuar con ellos simplemente se seleccionan el o los checkbox deseados, y se pulsa uno de los dos botones, el verde los arranca y el rojo los para en analogía con un equipo de música. La flecha circular de la esquina inferior derecha nos permite recargar la página.
El cuadro de errores:
En este cuadro se representan los errores mas comunes globalmente, es decir teniendo en cuenta todas las pasarelas. Siguiendo el estilo UNIX se muestran los porcentajes de error en los últimos 5, 10 y 15 minutos.
José Luis Pedrosa Montes
88
Pasarela X25­IP
Cuadro de gráficas:
En este cuadro se puede ver el applet con los gráficos de cada una de las pasarelas, informando del numero de transacciones correctas y erróneas, lineas verde y roja respectivamente.
Cuadro de estado de MySql:
Se muestran las principales variables que ofrece MySql mediante la ejecución de
diferentes comandos, como por ejemplo “show variables”
José Luis Pedrosa Montes
89
Pasarela X25­IP
Cuadro de entidades:
Este cuadro sirve para monitorizar las transacciones realizadas por las diferentes
entidades conectadas, mostrando por cada una de ellas el numero de correctas e incorrectas, el
tamaño de los colores representa de manera gráfica el porcentaje de correctas.
José Luis Pedrosa Montes
90
Pasarela X25­IP
6 INSTALACIÓN DEL HARDWARE Y SOFTWARE
José Luis Pedrosa Montes
91
Pasarela X25­IP
6.1 Instalación Hardware
Pese haberse hecho una clase (C++) específica para representar la conexión X25 y poder migrarlo en caso de que se considere necesario a otro hardware X25, es necesario la utilización de una tarjeta eicon (DiaLogic), en principio cualquiera de sus modelos que soporte X25 implementa el mismo interfaz y usan las mismas librerías, por lo tanto son absolutamente compatibles, esto fue comprobado en la fase de desarrollo ya que fue necesario codificar un cliente­
emulador en otra maquina independiente, usando un multiplexador. En esta maquina se instalo y configuro un modelo inferior de la tarjeta x25 una C90, que carecía de backup por RDSI así como menos rendimiento.
Por lo tanto, si se desea tener soporte para Backup por RDSI se debe usar el modelo C91 v.2, en caso contrario cualquier modelo de eicon es valido, todos ellos se conectan en un puerto PCI 32Bits. Como consecuencia del tipo de licencia del driver, el código fuente no esta disponible, por lo que no es posible compilar los módulos del kernel en la distribución o arquitectura deseada, estos drivers solo están disponibles para sistemas 32bits (y solo algunas distribuciones), lo que restringe su uso a procesadores Intel 32, o en su defecto una arquitectura x86_64 trabajando en modo 32 bits, desperdiciando gran capacidad de la máquina.
Durante las diversas instalaciones (entorno de pruebas y producción) no se encontraron conflictos con ningún otro dispositivo.
Pruebas:
■
Intel Pentium 4 ■
Controladoras IDE
■
Vídeo AGP
Desarrollo:
●
Intel Xeon
José Luis Pedrosa Montes
92
Pasarela X25­IP
●
Controladora SAS
●
Vídeo PCIX integrado en placa
●
3com Gbit Ethernet
Cabe señalar que Eicon usa un interfaz propietario, y en la mayoría de los casos el extremo que va a la línea X25 no concuerda con el usado habitualmente en España, es necesario adquirir un adaptador entre ellos.
Como se ha explicado en el capítulo anterior, debido los driver de Dialogic no son software libre, por lo que no pueden ser compilados para una distribución de Linux cualquiera, sino que por el contrario solo los tenemos disponibles para unas ciertas versiones del kernel en pocas distribuciones, en la actualidad los siguientes:
●
SuSE Linux Enterprise Server (SLES) 9 (kernel 2.6.5­X)
●
SuSE Linux Enterprise Server (SLES) 10 (kernel 2.6.5­X) ●
Red Hat Enterprise Linux 4.0 (kernel 2.6.X.EL) + Updates
Los diferentes drivers están disponibles para su descarga on­line en la pagina oficial de Eicon: http://www.eicon.com/worldwide/products/WAN/cn4linux.htm
Para el cliente se eligió RedHat 4 update 4, ya se considero como el mas común de entre estas dos opciones.
El proceso de configuración de la X25 es muy dependiente de la instalación especifica en la que se este haciendo, por lo que no se pueden dar un proceso definido, simplemente indicar que antes de poder usar la tarjeta es necesario ejecutar el proceso de configuración que se encuentra ubicado en /usr/lib/eicon/eccfg. Intentare dar una guía de los aspectos mas importantes: al arrancar el configurador nos encontramos con esta pantalla que nos informa del hardware detectado:
José Luis Pedrosa Montes
93
Pasarela X25­IP
Pulsamos F4 para continuar, nos encontramos con el menu principal:
Mediante el tabulador seleccionamos X25, como queda en el dialogo y volvemos a pulsar F4 para configurar la linea:
José Luis Pedrosa Montes
94
Pasarela X25­IP
El punto principal de este menú, es elegir si nuestra tarjeta X25 actua como DTE o como DCE, si se han contrado PVC con un derminado NRI es necesario especificarlo aqui, asi como si usaremos HDLC o SLDL, el resto de opciones se dejaron por defecto.
Si volvemos a pulsar F4 llegamos a otra pantalla en la que podemos especificar ajustar tiempos de time­out, asi como configuraciones mas precisas.
En nuestra instalación tampoco fue preciso modificar ningun valor. Si pulsamos dos veces F3 volvemos al menu principal:
José Luis Pedrosa Montes
95
Pasarela X25­IP
Selcionamos: Dialer selection y una vez mas F4 y podemos ver la configuracion general de la conexión entre la tarjeta y la línea:
Aqui podremos especificar algunos time­out, tampoco se modificaron sus valores, ahora pulsando F4 podremos especificar el tipo de conexión:
José Luis Pedrosa Montes
96
Pasarela X25­IP
Aquí especificamos RS232 en nuestro caso (puerto serie), contabamos. Ahora solo queda salir guardando los cambios y reiniciar el adaptador. José Luis Pedrosa Montes
97
Pasarela X25­IP
Para esto, basta con dirigirse a la misma carpeta en la que se encuentra el instalador y ejecutar „./eccard stop && ./eccard start“
Si al ejecutar el comando nos encontramos con un mesaje similar a este, quiere decir que no se ha especificado correctamente bien el interfaz o si la UTR o la tarjeta es quien marca el reloj.
El driver tambien queda instalado como un servicio pudiendo arrancarse desde /etc/init.d/EC_start y detenerse con /etc/init.d/EC_shut, tambien desde las librerias directamente con /usr/lib/eicon/eccard
A continuación especifico los componentes software/librerias necesarias para el
correcto funcionamiento de lapasarela así como de su interfaz web.
José Luis Pedrosa Montes
98
Pasarela X25­IP
6.2 Pasarela
En primer lugar, si se desea compilar en la máquina en la que se usará en lugar de en el objeto ya compilado, es necesario el compilador GCC++ version 4.x, el proceso de compilado esta automatizado mediante su correspondiente fichero Makefile, por lo tanto es necesario GNU Make 3.8 en adelante.
Para su interacción con MySql son necesarias las librerías cliente, normalmente conocidas como mysqlclient, una vez mas si se desea compilar en la misma máquina es necesario el correspondiente paquete develop mysqlclient­dev, que contiene las cabeceras, necesarias para el proceso de compilado. Es necesario bajar el paquete de la página de Mysql y después en el directorio en el que se descargo ejecutar:
„rpm ­U ­­nodeps mysql*“
Un a vez instalado, están todas las dependencias solucionadas, ya podemos compilar la pasarela: no movemos a la carpeta src y ejecutamos: „make“
Tras unos segundos el ejecutable estará en la misma carpeta. Posteriormente es necesario crear el directorio de instalacion de la pasarela
„mkdir /opt/x25ipd“
A continuación se moverá el ejecutable a esa carpeta:
„mv x25ipd /opt/x25ipd“
Para arrancar la pasarela es necesario crear un fichero de configuración: /opt/x25ipd/x25ipd.conf, o se puede copiar el que viene por defecto para tener una guía. En este fichero aparecen unos path por defecto para los ficheros de log, es necesario que la carpeta donde estan contenidos esos ficheros, si no se especifican valores a /var/log/x25ipd/ y es necesario que exista si no se especifica otro path.
José Luis Pedrosa Montes
99
Pasarela X25­IP
Los ficheros de configuración de la pasarela son leídos con la ayuda de la librería iniparser, no obstante no esta disponible en todas las distribuciones por lo que se ha incluido el código y al compilar se incluyen dentro del binario, por lo que no es necesaria su instalación, no obstante, en el Makefile se ha incluido una opción para que no se compilen y sean cargadas como una librería en tiempo de ejecución.
Normalmente las pasarelas de comunicaciones desean ser arrancadas como servicios, a tales efectos se ha incluido fichero de arranque para la distribución RedHat 4 que debe ser copiado en /etc/init.d, ajustandose al estándar de facto en Linux, de manera que puede ser arrancada o parada manuelamente mediante /etc/init.d/x25ipd, como opciones recibe:
●
start: arranca el proceso
●
stop: para la paserela
●
reload: vuelve a leer el fichero de configuración y carga los nuevos valores sin dejar de dar servicio a ningún cliente, de manera que solo las nuevas llamadas usaran esta configuración.
Si se desea que la pasarela arranque automáticamente durante al arranque es necesario ejecutar estos comandos que lo añaden al proceso de boot:
„chmod 755 /etc/init.d/ansiva
chkconfig ­­add ansiva
chkconfig ­­level 35 ansiva on
chkconfig ­­level 60 ansiva off“
En la maquina en la que se vaya a instalar el servidor MySql, ejecutamos:
„rpm ­U ­­nodeps mysql*“
Si no se ha creado ningún otro usuario, usuario root y contraseña vacia nos dan acceso a la base de datos:
José Luis Pedrosa Montes
100
Pasarela X25­IP
„mysqlclient ­u root“
Ese comando nos da acceso a consola de Mysql, una vez dentro ejecutamos el fichero que contiene la estructura de la base de datos. En primer lugar creara la base de datos ipx25d y después la estructura de las tablas, insertando una fila de ejemplo en cada una de ellas:
„source ipx25d.sql“
Este script no añade permisos para ningún usuario, es conveniente crear un usuario para que accedan tanto la pasarela como el servidor web.
José Luis Pedrosa Montes
101
Pasarela X25­IP
6.3 Bastionado del servidor
A continuación voy a explicar los pasos que se siguieron una vez terminada la instalación para conseguir mejorar la seguridad. Por defecto la instalación de RED HAT Enterprise 4 instala muchos servicios que la pasarela no necesita y los deja habilitados, a continuación se explica como deshabilitarlos todos aquellos que no eran necesarios para el proyecto según la funcionalidad descrita en el documento, no obstante en otras instalaciones es posible que fueran necesarios.
“chkconfig cups off”
“chkconfig cups­config­daemon off”
Estos son los servicios de impresión de Linux
“chkconfig ntpd on”
Este es el demonio de sincronización de reloj, es muy recomendable para tener una hora precisa de la realización de las transacciones.
“chkconfig iptables off”
El servicio iptables es un firewall para Linux, en el entorno de producción donde se instaló el servidor no era necesario un firewall por ordenador ya que toda la subred esta protegida.
“chkconfig portmap off”
Portmap se usa para poder recibir peticiones en las que se desconoce el puerto del servicio al que se quiere acceder. El servidor no recibe conexiones IP por lo que no es necesario.
“chkconfig netfs off”
Este servicio permite montar unidades remotas.
“chkconfig anacron off”
José Luis Pedrosa Montes
102
Pasarela X25­IP
“chkconfig atd off”
Estos dos servicios son programadores de tareas para Linux, son similares a Cron y no son necesarios, ya que se usara cron original
“chkconfig pcmcia off”
Servicio que permite usar hardware en tarjetas Pcmcia
“chkconfig sendmail off”
Agente de transporte de correo, solo para servidores de correo.
“chkconfig nfs off”
“chkconfig nfslock off”
NFS: (Network File System), usado para poder usar unidades de red como sistema de ficheros, permite el montaje.
“chkconfig rhnsd off”
Demonio para redes Red Hat tampoco es necesario.
“chkconfig smartd off”
Monitorización automática de los discos. Tal como se explico en el apartado de la web, es posible querer el habilitar el acceso por tsh en lugar de ssh, perdiendo seguridad pero ganando en rapidez, si así fuera es necesario ejecutar los siguientes comandos para habilitarlo:
“chkconfig ­­add tshd”
José Luis Pedrosa Montes
103
Pasarela X25­IP
“chkconfig ­­level 35 tshd on”
“chkconfig ­­level 60 tshd off”
Se aconseja editar el fichero /boot/grub/grub.conf y añadir esta opción al kernel, ya que permite ver muchas mas lineas de consola:
“vga=791”
José Luis Pedrosa Montes
104
Pasarela X25­IP
6.4 Entorno Web
A continuación se va a explicar como instalar en una Red HAT los componentes necesarios para el
entorno Web de la pasarela.
Servidor Web Apache v. 2.x, en nuestra instalación el servidor de bases de datos no
estaba en la misma maquina que el servidor web (muy habitual LAMP), de manera que también es
necesario el cliente MySQL en este servidor, al estar dentro de la red interna de la empresa, aislado
de la DMZ, no se han tomado consideraciones de seguridad mas allá de nombre de usuario y
contraseña.
Para instalar el servidor apache basta con ejecutar la siguiente secuencia de comandos una vez
introducido el CD de red-hat.
“mount /mnt/cdrom”
“rpm -Uvh apache-2.X.rpm”
“mount -t iso9660 /dev/cdrom /mnt/cdrom”
Dado que las paginas web están realizadas en scripting PHP es necesario la instalación del
modulo de ejecución PHP para apache. Para el desarrollo y entorno de producción se usó la versión
5.0. Desafortunadamente no existe el paquete para instalar en Red Hat (Oficial), a continuación se
explica como conseguir el modulo paraPHP:
En primer lugar es necesario descargar el archivo con los fuentes de la página oficial de php
http://php.net, se descarga en formato bzip o tar. El siguiente paso es descomprimir los fuentes
“tar xvf php*”
Crear los ficheros Makefile con el script:
“./configure”
Compilar los archivos
“make”
José Luis Pedrosa Montes
105
Pasarela X25­IP
Copiarlos a sus lugares de trabajo
“make install”
Si este proceso generase problemas en la instalación particular, siempre es posible
bajarse el paquete de la distribución Fedora Core, e instalarlo, pese a no ser para la misma
distribución
funciona
mcorrectamente.
http://redhat.download.fedoraproject.org/pub/fedora/linux/core/5/source/SRPMS/php-5.1.25.src.rpm
A continuación es necesario descargar las librerías para el manejo de servicios bajo
Windows, la url desde donde se puede acceder a dicho contenido: “http://snaps.php.net/win32/”, ha
de ser copiado en la carpeta “/lib/”, es necesario editar el fichero de configuración de apache,
normalmente ubicado en “/etc/httpd/modules.conf”, la linea para que sea capaz de usar PHP esta
comentada, basta con descomentarla para activarlo. Para las librerías de servicios, basta con copiar
esta linea y sustituir el modulo PHP por el de servicio.
La página web contiene HTML y el aplet de JfreeChart para las gráficas, el cual ya ha
sido incluido en los fuentes del proyecto, por lo que no es necesaria una descarga adicional.
Para el correcto funcionamiento de la interfaz web, es necesario que el cliente tenga la JRE o JDK
al menos 1.5. Este entorno web ha sido probado satisfactoriamente en los siguientes clientes :
●
Microsoft Internet Explorer, v. 6.x y 7.x
●
Mozilla Firfox v 1.5.x y 2.0.x
●
Mozilla Seamonkey
●
Opera WebBrowser
José Luis Pedrosa Montes
106
Pasarela X25­IP
7 FICHERO DE CONFIGURACIÓN
Para poder configurar la pasarela, al tratarse de un demonio y no tratarse de un proceso interactivo, es necesario, crear un fichero de configuración en “/opt/x25ipd/x25ipd.conf”, por defecto hay uno con valores de ejemplo. El fichero sigue la costumbre GNU:
[SECCIÓN]
Atributo 1 = valor1
Empezaré por describir las diferentes secciones: la principal es GLOBAL, que define los parámetros generales de la aplicación, BBDD en la cual se indican los valores necesarios para realizar la conexión contra MySql, SECTORN, las diferentes combinaciones de CUD y NRI validas así como donde enrutarlas, N debe empezar en 1. A continuación describiré cada uno de los campos de los sectores:
GLOBAL
localnri: NRI que esta asociado a la linea conectada a la tarjeta X25, si se posee centralita X25 que de extensiones, se pueden configurar en este campo. Este valor es obligatorio, sin el la aplicación no arrancará
syslog: esta variable solo puede tomar dos valores, yes o no, este parámetro no es obligatorio y de no ser especificado toma el valor no, así como si el valor no es correcto.
app_path: path completo al fichero que se desea que contenga el registro de log de la marcha de la pasarela. Este valor es opcional, de no ser especificado se usara: “var/log/x25ipd/x25ipd.log”
trx_path: se comporta de manera idéntica a la variable app_path, pero en este fichero se José Luis Pedrosa Montes
107
Pasarela X25­IP
registran las transacciones procesadas por la pasarela, valor por defecto: /var/log/x25ipd/x25trx.log
deb_path: path al fichero de debug, si es especificado, la pasarela registra en ese fichero las operaciones que realiza a un nivel mucho mas detallado, su fin es encontrar problemas con algún cliente.
BBDD
active: Puede tomar los valores “yes” o “no”, en caso de no especificarse se tomara como no
esto hace que la pasarela guarde o no registro de transacciones en base de datos, obsérvese que si se deshabilita esta opción la pagina de monitorización solo permitirá parar y arrancar y no se mostraran estadísticas
ip: ip al host que alberga la base de datos.
user: usuario para la conexión
password: contraseña para la conexión
port:puerto en el que escucha MySql si no se ha cambiado en la configuración es el puerto 3306, si no se encuentra este valor, se usara el valor por defecto
database: base de datos en la que se encuentran las tablas, esta dato es obligatorio, el script de creación de tablas, crea una base de datos ipx25d, a no ser que haya sido cambiada ese es valor correcto
queuetime: Este campo nos indica cada cuanto tiempo el hilo de base de datos debe intentar vaciar la cola con las querys pendientes, para unas 300 transacciones por minuto se aconseja un valor de entorno a 2000. Este valor se especifica en milisegundos. filecheck = 300 ; Seconds between file dump check && reconnect
José Luis Pedrosa Montes
108
Pasarela X25­IP
8 CONCLUSIONES
Durante la realización de este proyecto, he podido tener una mayor familiarización con
el sistema Linux, usando técnicas de programación de alto rendimiento, teniendo un mayor control
sobre lo que se esta produciendo en cada momento, las opciones de compilación, etc.
He podido aprender las ventajas e inconvenientes de la programación remota en
consola frente a los cada día mas extendidos IDE's. Los entornos de desarrollo integrado ofrecen
indudablemente unas grandes ventajas, como son la automatización de Sripts de compilado, ayuda
integrada, corrección de código dinámica, sugerencias ante errores. Sin embargo con estos IDE's en
el proceso de ayuda al desarrollador toman decisiones sin la intervención del usuario, tomando
usualmente valores por defecto, haciendo en muchos casos que se desconozca esa opción o el valor
que tomó, estos problemas no se dan al codificar desde un entorno mucho mas simple, como pueda
ser VIM, que simplemente ofrece “cuadros” de consola, y coloreado de texto.
El no tener acceso físico al servidor en el cual se desarrolla el proyecto tiene grandes
inconvenientes, como los depuradores remotos, GDB, pero obligan a tener un control mas
exhaustivo del proceso, como por ejemplo la memoria, eso implica que cada operación que se hace
ha de ser elegida tras considerar distintas opciones, consiguiendo un comportamiento mas
predecible y estable.
Pese a ser una tecnología de los años 70, este tipo de conexiones, siguen estando
vigentes en algunos contextos, ofreciendo un servicio prácticamente de banda estrecha pero un
muy buen rendimiento, con muy poco retraso comparado con una conexión a través de Internet.
Otro motivo de que estas lineas continúen vigentes es la resistencia al cambio, ya que en entornos
económicos, las evoluciones tecnológicas son vistas con gran reticencia.
José Luis Pedrosa Montes
109
Pasarela X25­IP
BIBLIOGRAFÍA
●
[BARR01] Barranco de Areba, Jesús, “Metodología del análisis estructurado de sistemas”, Universidad Pontificia Comillas, 2001
●
[WELL03] Welling, luke., Thomson, Laura., “Desarrollo Web con PHP y MySQl” Anaya 2003
●
[GALL03] Gallego Vazquez, José Antonio., “Desarrollo Web con PHP y MySQL”, Anaya 2003
●
[PD02] Dubois Paul., “MySQL”, Prentice Hall 2002
●
[MIMA]Mitchell, Mark, Oldham, Jeffrey, Advanced Linux Programming ­Threads­
●
Bradford Nichols, Dick Buttlar, Jacqueline Proulx Farrell PThreads Programming ­ A POSIX Standard for Better Multiprocessing ●
Mark Mitchell, Jeffrey Oldham, and Alex Samuel Advanced Linux Programming ­ Interprocess Communication
●
Protocolo de recargas para – Incluido en el documento.
●
Eiconcard Connections for Linux User’s Guide ●
[BEEJ]Beej's Guide to Network Programming - http://beej.us/guide/bgnet/
José Luis Pedrosa Montes
110
Pasarela X25­IP
GLOSARIO
Apache: Software diseñado para servidores Web.
API: (del inglés Application Programming Interface ­ Interfaz de Programación de Aplicaciones) es el conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que ofrece cierta librería para ser utilizado por otro software como una capa de abstracción.
Applet: es un componente de software que corre en el contexto de otro programa, por ejemplo un navegador web.
BUS: bus puede conectar lógicamente varios periféricos (o computadores) sobre el mismo conjunto de cables CUD: Call user data
C++: es un lenguaje de programación, diseñado a mediados de los años 1980, por Bjarne Stroustrup, como extensión del lenguaje de programación C.
DMZ: “De­Militarized Zone” (Zona Desmilitarizada).
DNS: “Domain Name System” (Sistema de Nombres de Dominio).
GCC: GNU C Compiler (Compilador C GNU). GCC es una colección de compiladores que admite varios
Clase: son declaraciones o abstracciones de objetos.
GNU: acrónimo recursivo que significa GNU No es Unix (GNU is Not Unix).
CRON: administrador regular de procesos en segundo plano (demonio) que ejecuta programas a intervalos regulares Demonio: daemon ó dæmon es un tipo especial de proceso informático que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario
José Luis Pedrosa Montes
111
Pasarela X25­IP
Driver: ó controlador de dispositivo es un programa informático que permite al sistema operativo interactuar con un periférico, haciendo una abstracción del hardware
Lenguajes: C, C++, Objective C, Chill, Fortran y Java así como también las librerías para éstos. Surgió de la imposibilidad de compilar en un entorno que no fuese PC bajo MS­DOS.
Firewall: (cortafuegos), es un elemento de hardware o software utilizado en una red de computadoras para controlar las comunicaciones, permitiéndolas o prohibiéndolas según las políticas de red
GDB: “GNU Debugger” (Deopurador GNU).
Hilo: un proceso que representa una secuencia simple de instrucciones ejecutada en paralelo con otras secuencias.
HTML: “HyperText Markup Language” (Lenguaje de Marcas de Hipertexto).
HTTP: “Hypertext Transport Protocol” (Protocolo de transferencia de Hipertexto).
HDLC: (High­Level Data Link Control) es un protocolo de comunicaciones de datos punto a punto entre dos elementos basado en el ISO 3309
IP: “Internet Protocol” (Protocolo de Internet).
JAVA: Es un lenguaje de programación orientado a Internet con el cual se escriben aplicaciones para servidores Web y para clientes. Permite ejecutar animaciones y elementos interactivos de una página Web con un interprete de dicho lenguaje del que disponen todos los navegadores de Internet modernos.
JDK: “Java Development Kit”
LAPB : (Link Access Procedure, Balanced) es un protocolo de nivel de enlace de datos dentro del conjunto de protocolos de la norma X.25. LAPB está orientado al bit y deriva de HDLC. Modifica a este último para que cualquiera de los dos nodos pueda iniciar la transmisión, por esto se ha denominado balanceado.
Librería: es un conjunto de procedimientos y funciones (subprogramas) agrupadas en un archivo José Luis Pedrosa Montes
112
Pasarela X25­IP
con el fin de ser aprovechadas por otros programas. Al proceso de hacer accesibles estos subprogramas al programa principal se le llama enlace (link).
Log: Fichero, normalmente de texto plano en el que se registran los sucesos de un programa.
Modulo: tareas útiles del sistema (generalmente denominadas servicios) se delegan a pequeños fragmentos de software conocidos como módulos. En general, estos módulos se pueden cargar y descargar del sistema
Memory Leak: Es un tipo de consumo inintencionado de memoria por un programa
MYSQL: Es un Sistema Gestor de Bases de Datos Relacionales (RDBMS, Relational data­ base Management System).
NUA: Network User Address.
NRI: NUA.
OPENSSL: El software OpenSSL es un proyecto de software desarrollado por lo miembros de la comunidad Open Source. Es un robusto juego de herramientas que le ayudan a su sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la seguridad, tales como el Transport Layer Security (TLS).
OSI: Organización Internacional para la Estandarización o International Organization for Standarization (ISO)
PHP: Es uno de los lenguajes de lado servidor más extendidos en la Web. Nacido en 1994, se trata de un lenguaje de creación relativamente creciente que ha tenido una gran aceptación en la comunidad de webmasters debido sobre todo a la potencia y simplicidad que lo caracterizan.
PCI: Peripheral Component Interconnect (PCI, "Interconexión de Componentes Periféricos") consiste en un bus de ordenador estándar para conectar dispositivos periféricos directamente a su placa base
PVC: Permanent Virtual Circuit
Red Hat: compañía responsable de la creación y mantenimiento de una distribución del sistema José Luis Pedrosa Montes
113
Pasarela X25­IP
operativo GNU/Linux que lleva el mismo nombre: Red Hat Linux.
RPM: “Redhat Package Manager” Sistema utilizado en Unix para ayudar a la instalación de diferentes paquetes de software. Similar a lo que seria un “.exe” en Windows. SQL: “Structured Query Language” (Lenguaje estructurado de consultas).
RS­232: (también conocido como Electronic Industries Alliance RS­232C) es una interfaz que designa una norma para el intercambio serie de datos binarios entre un DTE (Equipo terminal de datos) y un DCE (Data Communication Equipment, Equipo de terminación del circuito de datos), aunque existen otras situaciones en las que también se utiliza la interfaz RS­232.
Script: es un programa usualmente simple, que generalmente se almacena en un archivo de texto plano. Semáforo: es una variable especial protegida (o tipo abstracto de datos) que constituye el método clásico para restringir o permitir el acceso a recursos compartidos
Socket: designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo de datos, generalmente de manera fiable y ordenada.
SSH: (Secure SHell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red.
SSL: “Secure Sockets Layer” (Protocolo de Seguridad).
Syslog: es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.
Tabla hash: mapa hash: es una estructura de datos que asocia llaves o claves con valores. La operación principal que soporta de manera eficiente es la búsqueda
TCP: “Trasmision Control Protocol” (Protocolo de Control de Trasmisiones).
TCP/IP: “Trasmision Control Protocol/ Internet Protocol”. José Luis Pedrosa Montes
114
Pasarela X25­IP
UML: por sus siglas en inglés, (Unified Modeling Language) es el lenguaje de modelado de sistemas de software por excelencia
URL: “Uniform Resource Locator” (Localizador uniforme de recursos).
URI: Uniform Resource Identifier, identificador uniforme de recursos
X.25: estándar UIT-T para redes de área amplia de conmutación de paquetes.
José Luis Pedrosa Montes
115
Pasarela X25­IP
ANEXO A CONECTORES X25
Debido a los múltiples estándar a los que se ha adaptado X25, y a las diversas formas en las que se entrega al cliente las lineas X25 se incluye a continuación los esquemas de conexión entre los conectores mas comunes. Por otro lado, es muy complicado encontrar algún distribuidor o empresa que tenga estos cables, por lo tanto, los mas probable es que sea necesario construirlos dependiendo de la instalación o llevar el esquema a alguna establecimiento especializado en electrónica José Luis Pedrosa Montes
116
Pasarela X25­IP
José Luis Pedrosa Montes
117
Pasarela X25­IP
ANEXO B CODIGOS X25
A continuación se incluye una lista con los códigos de error que proporcionan las librerías del driver de Eicon. El segundo campo de esta tabla son los correspondientes “defines” de la Api que nos proporciona. Durante el desarrollo del proyecto muchos de estos defines han sido usados para conseguir el comportamiento idóneo, solo abortando la comunicación en casos de errores no recuperables.
Errores de la API
José Luis Pedrosa Montes
118
Pasarela X25­IP
Errores en la red:
José Luis Pedrosa Montes
119
Pasarela X25­IP
Constantes:
José Luis Pedrosa Montes
120