1 APLICACION Y DESARROLLO DE PROTOCOLO DE
Anuncio
APLICACION Y DESARROLLO DE PROTOCOLO DE COMUNICACIÓN MEDIANTE
SISTEMA EMBEBIDO (POS)
Johan Mauricio Prieto Vargas
UNIVERSIDAD DISTRITAL
“Francisco José De Caldas”
Facultad Tecnológica
Bogotá D.C.
Agosto del 2015
1
APLICACION Y DESARROLLO DE PROTOCOLO DE COMUNICACIÓN MEDIANTE
SISTEMA EMBEBIDO (POS)
Código del Proyecto 201501273065
Johan Mauricio Prieto Vargas Código: 20131273014
Monografía para optar por el título de:
Ingeniero En Telecomunicaciones
Director:
Edward Jacinto Gómez
UNIVERSIDAD DISTRITAL
“Francisco José De Caldas”
Facultad Tecnológica
Bogotá D.C.
Agosto del 2015
2
APLICACION Y DESARROLLO DE PROCOLO DE COMUNICACIÓN MEDIANTE
SISTEMA EMBEBIDO (POS)
PAGINA DE APROBACIÓN
Observaciones
_____________________________________________________________
_____________________________________________________________
______________________________________________________________
______________________________________
Ingeniero Edward Jacinto Gómez
Director del Proyecto
_____________________________________
Ingeniero Jorge Eduardo Porras Bohada
Jurado 1
_____________________________________
Jurado 2
Fecha de Presentación Agosto del 2015.
3
AGRADECIMIENTOS
Expreso mis agradecimientos a:
Cada una de las personas que han hecho posible que el día de hoy me encuentre preparando mi
proyecto de grado, que han hecho posible que uno de mis sueños de niño esté a punto de convertirse
en realidad. A mis compañeros, por depositarme confianza en momentos decisivos y anteponernos a
un sin número de dificultades que se presentaron en el camino hasta el día de hoy. Gracias a la ayuda
de ellos ha sido posible llegar hasta este punto. Comparto y brindo un especial agradecimiento a mi
abuela paterna ya fallecida, la cual ha hecho de mí la persona que soy, gracias a ella por permitirme
distinguir los caminos que se pueden tomar en la vida. A mis padres por su entrega para que yo
pudiera salir adelante en cada uno de mis proyectos, por dejar de pensar en ellos y tenerme como
referencia de su vida. Gracias a los docentes, aquellos que marcaron cada etapa de mi camino
universitario, y que me ayudaron en asesorías y dudas presentadas en la elaboración de cada una de
las actividades académicas que comprenden esta carrera, que por mí es considerada a partir de este
momento como un estilo de vida.
4
TABLA DE CONTENIDO
AGRADECIMIENTOS.................................................................................................................................... 4
GLOSARIO ................................................................................................................................................... 11
RESUMEN..................................................................................................................................................... 13
ABSTRACT ................................................................................................................................................... 14
INTRODUCCIÓN ......................................................................................................................................... 15
1 .PREELIMINAR ......................................................................................................................................... 16
1.1
Descripción del problema.................................................................................................... 16
1.2 Justificación ............................................................................................................................ 16
1.2.1 Impacto Social ............................................................................................................................. 16
1.2.2 Impacto Económico ..................................................................................................................... 17
1.3 Metodología Usada ................................................................................................................ 17
2. OBJETIVOS .............................................................................................................................................. 18
2.1 Objetivo General ...................................................................................................................... 18
2.2 Objetivos Específicos ............................................................................................................... 18
3. MARCO TEÓRICO Y ESTADO DEL ARTE ........................................................................................... 19
3.1
Sistemas Embebidos ............................................................................................................ 19
3.1.1 Sistema embebido a utilizar ......................................................................................................... 20
3.1.1.1 TPV (Terminal Punto de Venta) ................................................................................. 21
3.2 Estándares de comunicación, sistemas embebidos................................................................. 22
3.2.1 Comunicación GPRS (Global Packet Service) .............................................................................. 22
3.2.2 WCDMA(Acceso múltiple por división de código de banda ancha) ............................................. 25
3.3 TCP/IP .................................................................................................................................... 26
3.3.1 Puertos TCP/IP ............................................................................................................................ 28
3.3.2 Sockets .......................................................................................................................................... 30
3.4 PPP ( Point to Point Protocol ) ............................................................................................... 31
3.5 FTP (File Transfer Protocol) .................................................................................................. 33
3.6 HTTP ...................................................................................................................................... 34
3.7 Protocolo ISO8583 ................................................................................................................. 35
3.8
Compresión y descompresión de datos ............................................................................... 38
5
3.8.1
¿Para que se comprimen datos? .............................................................................................. 38
3.8.2
¿Que es la compresión de datos? ............................................................................................ 38
3.8.3
Tipos de compresión ............................................................................................................... 38
3.8.4
Métodos de compresión .......................................................................................................... 39
3.8.5 Compresión con perdida de datos ................................................................................................ 39
3.8.6 Compresión sin perdida de datos ................................................................................................. 40
3.8.7 Formato 7z .................................................................................................................................. 40
3.8.8 Algoritmo LZMA .......................................................................................................................... 41
3.9 Apuestas en República Dominicana ......................................................................................... 41
3.10 Descripción y definición de la red a utilizar. .......................................................................... 44
3.10.1 Definición del método de transmisión de datos cliente-servidor. ................................................. 44
3.11 Estado del arte......................................................................................................................... 45
3.11.1 Proyecto 1:................................................................................................................................... 46
3.11.2 Proyecto 2:................................................................................................................................... 46
3.11.3 Proyecto 3:................................................................................................................................... 47
3.11.4 Proyecto 4:................................................................................................................................... 47
3.11.5 Proyecto 5:................................................................................................................................... 48
3.11.6 Proyecto 6:................................................................................................................................... 48
4. DISEÑO DE PROTOCOLO DE COMUNICACIÓN Y DESARROLLO DE LÓGICA SOBRE
SISTEMA EMBEBIDO ................................................................................................................................. 48
4.1 TCP – IP ................................................................................................................................... 49
4.2
GPRS ................................................................................................................................... 50
4.3 Diagrama de flujo del desarrollo completo (Con protocolo de comunicación implícito) ........ 53
4.4 Diagrama de clases básicas del desarrollo................................................................................ 55
........................................................................................................................................................ 55
4.5 Diagrama de casos de uso ...................................................................................................... 55
4.6 Transacciones implementadas ................................................................................................ 57
4.6.1 Login-Inicialización....................................................................................................................... 57
4.6.2 Transacción de venta ..................................................................................................................... 63
4.6.3 Transacción de reversión ............................................................................................................... 67
4.6.4 Transacción de anulación .............................................................................................................. 68
4.6.5 Transacción de Batch Upload ........................................................................................................ 70
6
4.6.6 Transacción de lista de números .................................................................................................... 70
4.6.7 Transacción de consulta de ventas ............................................................................................... 73
4.6.8 Transacción de pagos ..................................................................................................................... 76
4.6.9 Transacción de consulta de tiquetes ............................................................................................... 77
4.6.10 Transacción de cierre de ventas ................................................................................................... 78
4.6.11 Transacción de Reporte Parcial ................................................................................................... 79
4.6.12 Transacción de consulta de tiquetes ganadores ................................................................ 81
4.6.13 Transacción de consulta de cierre por fecha ................................................................................ 83
4.6.14 Transacción de sincronización ..................................................................................................... 84
4.6.15 Transacción de Informe al final del sorteo .......................................................................... 87
4.6.16 Recargas .................................................................................................................................... 89
4.7 Mensajería ISO 8583 ................................................................................................................ 92
5. RESULTADOS .......................................................................................................................................... 94
5.1 Posibles Fallas o Causas de error ............................................................................................. 94
5.1.1 Perdida de los datos descargados ................................................................................................... 94
5.1.1.1 Pérdida de Alimentación ............................................................................................ 94
5.1.1.2 Reinicio Inesperado.................................................................................................... 94
5.1.1.3 Falla de Comunicación............................................................................................... 95
5.1.2 Recepción errónea de la información. ............................................................................................ 95
5.1.3 Envío inadecuado de la información por parte del servidor ........................................................... 96
5.1.4 Exceder la cantidad de datos que se pueden enviar a la impresora térmica .................................... 97
5.1.5 Interrupción de procesos por duración de la batería ....................................................................... 97
5.1.6 Exceder los campos de respuesta en las consultas y los reportes ................................................... 97
5.1.7 Validación de ventas offline como total de ventas en el cierre ...................................................... 97
5.1.8 Validación en la generación de reversos y la sincronización ......................................................... 98
5.1.9 Error en la generación del código de venta del tiquete offline ....................................................... 98
5.2 Descripción del Sistema de descarga remota ........................................................................... 99
5.2.1 Almacenamiento ............................................................................................................................ 99
5.2.2 Descompresión .............................................................................................................................. 99
5.3 Variables del Sistema .............................................................................................................. 102
CONCLUSIONES ....................................................................................................................................... 103
BIBLIOGRAFÍA .......................................................................................................................................... 104
7
LISTA DE TABLAS
Tabla 1: ALGUNOS PUERTOS CONOCIDOS ............................................................................................................. 30
Tabla 2: CAMPOS ISO 8583 ........................................................................................................................................36
Tabla 3: METODOS DE COMPRESIÓN INTEGRADOS A 7Z...................................................................................... 41
Tabla 4: CABECERA DE VENTAS ............................................................................................................................... 60
Tabla 5: TABLA DE JUEGOS .......................................................................................................................................60
Tabla 6: TABLA DE PIE DE TIQUETES ...................................................................................................................... 61
Tabla 7: TABLA DE PRODUCTOS ............................................................................................................................... 62
Tabla 8: CABECERA DE LA VENTA ............................................................................................................................ 64
Tabla 9: DETALLE DE LA VENTA ............................................................................................................................... 65
Tabla 10: RESPUESTA DE VENTA .............................................................................................................................. 66
Tabla 11: ENVÍO DE ANULACIÓN .............................................................................................................................. 69
Tabla 12: RESPUESTA DE ANULACIÓN..................................................................................................................... 69
Tabla 13: ENVÍO DE BATCH.......................................................................................................................................71
Tabla 14: CABECERA LISTA NÚMEROS..................................................................................................................... 71
Tabla 15: DETALLE DE RESPUESTA LISTA NÚMEROS............................................................................................. 72
Tabla 16: ENVÍO DE CONSULTA ................................................................................................................................ 74
Tabla 17: RESPUESTA DE CONSULTA ....................................................................................................................... 75
Tabla 18: ENVÍO DE PAGOS .......................................................................................................................................76
Tabla 19: RESPUESTA DE PAGOS .............................................................................................................................. 76
Tabla 20: ENVÍO CONSULTA TIQUETES ................................................................................................................... 77
Tabla 21: ENVÍO DE CIERRE .....................................................................................................................................78
Tabla 22:RESPUESTA DEL CIERRE............................................................................................................................ 78
Tabla 23: REPORTE PARCIAL ENVÍO ........................................................................................................................ 80
Tabla 24: RESPUESTA REPORTE PARCIAL ............................................................................................................... 80
Tabla 25: CONSULTA DE TIQUETES GANADORES ..................................................................................................81
Tabla 26: RESPUESTA TIQUETES GANADORES .......................................................................................................81
Tabla 27: DETALLE DE RESPUESTA TIQUETES GANADORES ................................................................................ 82
Tabla 28: ENVÍO DE CIERRE POR FECHA ................................................................................................................ 83
Tabla 29: RESPUESTA DE CIERRE POR FECHA .......................................................................................................83
Tabla 30: ENVÍO DE SINCRONIZACIÓN .................................................................................................................... 85
Tabla 31: DETALLE DEL ENVÍO EN SINCRONIZACIÓN ........................................................................................... 85
Tabla 32: RESPUESTA DE SINCRONIZACIÓN ...........................................................................................................86
Tabla 33: ENVÍO CONSULTA SINCRONIZACIÓN ......................................................................................................87
Tabla 34: RESPUESTA CONSULTA SINCRONIZACION ............................................................................................. 87
Tabla 35: INFORME AL FINAL DEL SORTEO TX ......................................................................................................88
Tabla 36: RESPUESTA DEL INFORME AL FINAL DEL SORTEO............................................................................... 88
Tabla 37: ENVÍO DE RECARGAS ................................................................................................................................ 90
Tabla 38: DETALLE DEL ENVÍO DE RECARGAS.......................................................................................................90
8
Tabla 39: RESPUESTA PARA RECARGAS ................................................................................................................... 91
Tabla 40: Tags CAMPO PRIVADO ............................................................................................................................... 94
Tabla 41: DATOS PRÁCTICOS DESCARGA GPRS ................................................................................................... 101
Tabla 42:IMPLEMENTACIÓN CONSULTA SINCRONIZACIÓN................................................................................ 101
Tabla 43: DISMINUCIÓN DEL PROCESO DE REVERSO ........................................................................................ 101
Tabla 44:VARIABLES DEL SISTEMA......................................................................................................................... 102
LISTA DE ILUSTRACIONES
Ilustración 1: TERMINAL PAX S90 .............................................................................................................................. 19
Ilustración 2: ARQUITECTURA GPRS ........................................................................................................................ 23
Ilustración 3: GPRS PROTOCOLO DE SEGUNDA GENERACIÓN ............................................................................25
Ilustración 4. WCDMA VS CDMA ................................................................................................................................ 26
Ilustración 5: OSI VS TCP/IP .......................................................................................................................................26
Ilustración 6: CABECERA TCP....................................................................................................................................28
Ilustración 7: POINT TO POINT PROTOCOL ............................................................................................................. 32
Ilustración 8: SISTEMA PUNTO A PUNTO ................................................................................................................. 33
Ilustración 9: FTP ........................................................................................................................................................ 34
Ilustración 10: COMPRESIÓN Y DESCOMPRESIÓN DE ARCHIVOS ........................................................................38
Ilustración 11: COMPRESÍON SIMÉTRICA................................................................................................................. 39
Ilustración 12:ESQUEMA TCP ....................................................................................................................................50
Ilustración 13:CONFIGURACÍON BANDAS................................................................................................................ 51
Ilustración 14: CONFIGURACIÓN APN. ..................................................................................................................... 51
Ilustración 15: INGRESAR APN ...................................................................................................................................52
Ilustración 16: INGRESAR USUARIO SIN APN ...........................................................................................................52
Ilustración 17: INGRESAR CONTRASEÑA .................................................................................................................. 52
Ilustración 18: DIAGRAMA DE FLUJO CONEXIÓN GPRS ........................................................................................ 53
Ilustración 19: DIAGRAMA DE FLUJO PRINCIPAL ...................................................................................................54
Ilustración 20: DIAGRAMA DE CLASES ..................................................................................................................... 55
Ilustración 21: CASOS DE USO ...................................................................................................................................56
Ilustración 22: LOGIN ................................................................................................................................................. 57
Ilustración 23: MENU PRINCIPAL .............................................................................................................................. 63
Ilustración 24: MODO OFFLINE.................................................................................................................................64
Ilustración 25: GRILLA ................................................................................................................................................ 65
Ilustración 26: VENTA APUESTA.................................................................................................................................67
Ilustración 27: TIQUETE DE VENTA........................................................................................................................... 67
Ilustración 28: REVERSO EXITOSO ............................................................................................................................ 68
Ilustración 29: CAMPO DE ANULACIÓN ................................................................................................................... 69
Ilustración 30: MENU CONSULTAS ............................................................................................................................ 71
Ilustración 31: PARAMETROS DE CONSULTAS .........................................................................................................72
Ilustración 32:TIQUETE DE LISTA DE NÚMEROS ....................................................................................................73
Ilustración 33: PARAMETROS DE REPORTE ............................................................................................................. 75
Ilustración 34: TIQUETE CONSULTA GENERAL .......................................................................................................75
9
Ilustración 35: CONSULTA DE TIQUETES ................................................................................................................. 77
Ilustración 36: PANTALLA DE CIERRE ....................................................................................................................... 79
Ilustración 37: SELECCIONAR LOTERIA EN REPORTE PARCIAL ............................................................................79
Ilustración 38: TIQUETE DE REPORTE PARCIAL .....................................................................................................80
Ilustración 39: REPORTE DE TIQUETES GANADORES ............................................................................................ 82
Ilustración 40: REPORTE DE CIERRE POR FECHA ..................................................................................................84
Ilustración 41: PANTALLA DE SINCRONIZACIÓN .....................................................................................................86
Ilustración 42: TIQUETE DEL INFORME AL FINAL DEL SORTEO ...........................................................................89
Ilustración 43: PARAMETRO DE RECARGAS ............................................................................................................. 89
Ilustración 44: CONFIRMACIÓN DE RECARGA ........................................................................................................91
Ilustración 45: TIQUETE DE RECARGA ..................................................................................................................... 92
Ilustración 46: MENSAJERIA DE ESCARGA REMOTA tx ........................................................................................... 92
Ilustración 47: MENSAJERIA DE DESCARGA REMOTA RX ....................................................................................... 93
Ilustración 48: CALCULO DEL CRC ........................................................................................................................... 96
Ilustración 49: CONFIGURACIÓN DESCARGA REMOTA ........................................................................................ 100
Ilustración 50: CONFIGURACIÓN IP ....................................................................................................................... 100
Ilustración 51: CONFIGURACIÓN PUERTO ............................................................................................................ 100
Ilustración 52: TIPO DE OPERADOR ....................................................................................................................... 100
Ilustración 53: INGRESO MANUAL DE OPERADOR ............................................................................................... 101
10
GLOSARIO
GPRS
Servicio general de paquetes vía radioenlace.
TCP
Protocolo de contro de transmision.
PPP
Protocolo punto a punto.
SSL
Capa de conexión segura.
FTP
Protocolo de transferencia de archivos.
SFTP
SSH File Transfer Protocol o Secure File Transfer Protocol.
HTTP
Protocolo de transferencia de hipertexto.
HTTPS
Protocolo de transferencia de hipertexto seguro.
ISO8583
Standard Para Transacciones Financieras.
GSM
Sistema global para las comunicaciones mobiles.
IEEE
Institute of Electrical and Electronics Engineers.
TPV
Terminal Punto de Venta o Datafono.
Bidireccioal
Envía y recibe.
SIM
Modulo de identificación de subscriptor.
IP
Etiqueta numérica que identifica una interfaz dentro de una red que utilice
protocolo IP.
POS
Point of sale (Punto de venta).
APN
Acces point name.
URL
Localizador de recursos uniforme.
TPDU
Transport Protocol Data Unit.
MTI
Indicador de tipo de mensaje.
C.S.I
Costumer service information.
POS
Point of sale.
WCDMA
Acceso múltiple por división de código de banda ancha.
TFTP
Protocolo de transferencia de archivos trivial.
DNS
Sistema de Nombres de Dominio.
SNMP
El Protocolo Simple de Administración de Red.
Octeto
Equivale a 8 bits, exactamente a 1 Byte.
API
Interfaz de programación de aplicaciones
11
Socket
API para TCP/IP
Unix
Sistema operativo portable, multitarea y multiusuario
Linux
Sistema operativo de software libre y código abierto.
Login
Ingreso a una plataforma o sistema con credenciales.
Tag
Etiqueta de lenguaje marcado.
AES
Estándar de encripción avanzado
Hash
Tipo de funciones con una salida alfanumérica de longitud normalmente fija que
representa un resumen de toda la información.
SHA
Algoritmo de hash seguro.
LZMA
Algoritmo de compresión de Lempel-Ziv-Markov.
NFS
Sistema de archivos de red.
LCP
Protocolo de control de enlace.
Pale
Juego de 4 dígitos en República Dominicana.
Quiniela
Juego de azar de 2 dígitos.
Berkeley
Distribución de software Berkeley de la universidad de california (BSD).
12
RESUMEN
La sistematización de procesos de compra y venta de gran variedad de tipos de servicios hace parte de
la evolución que tenemos día a día gracias al conocimiento de nuevas tecnologías que se presentan en
nuestro diario vivir. Siempre hay una forma más eficiente y diferente de realizar variedad de procesos,
en este caso se desea eliminar por completo los registros manuales en el tema de las apuestas, al igual
que olvidarse de la inseguridad que puede existir en cada una de las transacciones que se realizan a
diario en un sistema de apuestas (autenticidad del tiquete de venta).
La idea es utilizar un sistema embebido que funciona a manera de POS para que sea posible realizar
ventas en cualquier tipo de localidad contando con conexión inalámbrica mediante los operadores de
celular disponibles en República Dominicana. Este POS contara con periféricos de entrada y de salida
(teclado, impresora, pantalla, modem), lo que permitirá un flujo de entrada y salida de datos muy
dinámicos, para procesar y registrar directamente esta información en el servidor principal de la
compañía, lo cual automatizará los procesos de venta y consulta de la empresa y realizará las ventas
en tiempo real.
Actualmente entidades como los bancos utilizan TPV (Terminal punto de venta) como el método de
pago más utilizado por sus clientes, esto se debe al alto nivel de seguridad incorporado, la sencillez de
uso, la diversidad de medios de comunicación, la variedad de distribuidores y la capacidad de
portabilidad del dispositivo. Lo anterior indica que no solo se desarrollarán las ventas en un ámbito
más seguro y eficiente, sino que probablemente la cantidad de personas que poseen el hábito de
apostar pueda aumentar debido a la posibilidad que existirá de realizar otro tipo de transacciones por
este medio (POS).
13
ABSTRACT
The systematization of processes of Purchase and Sale of many different types of services are part of
the evolution that we have every day thanks to the knowledge of new technologies that arise in our
daily lives. There is always a more efficient and different form for to do many processes, in this case
we want to completely eliminate manual records on the subject of gambles, like forget the insecurity
that may exist in each of the transactions that daily made in a gambles system (Authenticity of the
voucher sales).
The idea is to use the system embedded that operates like a POS for making sales in any Location
including wireless connection using the Cellular Operators Available in the Dominican Republic.
This POS will have peripherals of input and output (keyboard, printer, screen, modem), allowing a
flow in and out of very Dynamic Data Processing and for to process and register directly that
information in the primary server for the company, which will automate the sales process and
consultations of the enterprise and will perform real-time sales.
Currently entities such as banks use POS (Point of Sale) as the method of payment used more for their
customers, this is due to the high level of security incorporated, simplicity of use, Media Diversity,
the Variety of distributors and the capacity of portability device. This indicates that not only sales will
develop in an environment safer and more efficient, otherwise that probably the number of persons
that have the habit of bet can increase because of the possibility to make another types of transactions
through of this device (POS).
14
INTRODUCCIÓN
El proyecto cuenta con el propósito de diseñar, construir e implementar un aplicativo que este en
capacidad de comunicarse con un sistema de venta, consulta y sincronización de Terminales Punto de
Venta (TPV) para una entidad de apuestas ubicada en República Dominicana, con el fin de
sistematizar el mercado de los juegos de azar en dicho país, además de facilitar el mercado de los
operadores de celular al implementar igualmente un sistema (TPV) para realizar recargas. Se pretende
mejorar los resultados de sistemas que brindan servicios similares en la actualidad.
El número de dispositivos adquiridos por esta entidad con el paso del tiempo puede ser considerable,
se habla de dos mil (2.000) a tres mil (3.000) unidades en promedio. Cada una de estas unidades debe
ser actualizada con cada cambio que solicite el cliente. Esto implica un proceso en el que un
representante de la empresa responsable de las terminales debe acercarse a cada punto geográfico en
donde esté ubicado el dispositivo a actualizar.
Debido a la gran cantidad de terminales en producción también se implementó un módulo de software
con la capacidad de actualizar la aplicación principal de manera remota vía GPRS. De este modo se
agiliza este proceso disminuyendo costos y tiempos.
15
1 .PREELIMINAR
1.1 Descripción del problema
Debido a las apuestas ilegales en República Dominicana, no solo se pierden recursos del estado sino
que se pierden dividendos en la empresa promotora de juegos de azar. Al canalizar la cantidad de
apuestas ilegales que se producen en este territorio, se puede no solo generar mucho más capital para
la empresa promotora, sino que se tiene la posibilidad de generar muchos más recursos públicos de
manera indirecta. Por otra parte los clientes tienen la posibilidad de confiar plenamente en este tipo de
juegos, ya que al estar totalmente legalizados, los premios estarán garantizados y podrán apostar de
manera segura.
Es importante conocer que el despliegue que se hace al apostar con papel escrito es mucho más denso
que el proceso que indica una transacción electrónica, es claro que la idea de la automatización no
solo incluye seguridad en el proceso de venta, sino que garantiza la transparencia en la generación de
la apuesta misma, debido a los datos de venta que proporciona el desprendible generado por el POS
en la apuesta.
1.2 Justificación
La exigencia del mercado en cuanto a la automatización de procesos es cada vez más alta debido a la
posibilidad de encontrar cada vez menos errores humanos, lo primordial es construir una propuesta de
bajos costos pero que a la vez tenga una versatilidad bastante significativa.
Gracias al diseño de la mensajería, el proyecto ha generado un impacto exitoso en el mercado de las
apuestas, debido a la dinámica que se implemento en los protocolos de comunicación entre servidor y
cliente, esta posibilidad permite que sea posible jugar cualquier tipo de lotería controlando
plenamente los horarios de cierre y sorteo de las mismas, además del diseño de transacciones de
consulta, las cuales permiten al usuario estar informado en tiempo real del inventario que tiene el
servidor y contrastarlo con el dinero que ha recibido en el transcurso de la jornada.
Es posible realizar procesos de actualización remota de software, por medio de un módulo que se
implemento, lo cual ha generado grandes beneficios tanto para la entidad que controla las apuestas
como para el usuario final, esto se debe a que cualquier tipo de nuevo requerimiento o ajuste a realizar
en el funcionamiento del dispositivo se entregará rápidamente y su puesta en marcha es más
dinámica.
1.2.1 Impacto Social
El desarrollo de tecnologías sobre sistemas embebidos permite ampliar los conocimientos en este
campo y crear nuevas técnicas para afrontar problemas de tipo tecnológico, mejorando
16
académicamente los niveles de aprendizaje, posicionando a la Universidad Distrital Francisco José de
Caldas cómo ente investigadora en la aplicación de nuevas tecnologías; de esta manera la apropiación
del conocimiento de los estudiantes va mucho más allá de los limites que imponen tecnologías
convencionales.
El proyecto lejos de excluir a varios grupos sociales, incluye muchas más personas, debido a la
generación de empleo, ya que existirán muchos más puntos de venta, consecuencia de la portabilidad
que posee el sistema embebido.
1.2.2 Impacto Económico
Tener un control seguro del dinero que produce el negocio de las apuestas es indispensable, sobre
todo en un país en auge como República Dominicana ya que en sus inicios la falta de disponibilidad
de los medios de tecnología de información, control y comunicación avanzada, creaba una serie de
pérdidas financieras, que poco a poco se ha ido corrigiendo.
Al hacer referencia acerca de una relación costo beneficio nos adentramos en un tema bastante
interesante a nivel económico, ya que sin perdidas ni dineros fraudulentos, las bancas nos dicen que
los beneficios son 1.34 veces más que los costos. Este es un valor privilegiado tomando como base la
inversión que se debe realizar, teniendo en cuenta un periodo de tiempo de 5 años, lo que indica que
definitivamente el negocio es bastante lucrativo si se lleva de la mejor manera y se evitan la fuga de
dineros por utilizar métodos clasicos (Castillo, 2014).
Con la inversión en tecnología y seguridad la relación costo beneficio no solo se mantiene sino que ha
tenido mejoras debido a los puntos de venta que se multiplican en las grandes ciudades donde se
centraliza por obvias razones el volumen más alto de consumidores.
1.3 Metodología Usada
A continuación se describe la metodología empleada la cual se divide en fases:
Como punto de inicio se hace la lectura total del documento enviado por parte del usuario del
aplicativo. Por medio de este documento se comienza a establecer la arquitectura para la
solución de la situación planteada. Se hace un alcance real del mismo y los posibles puntos
críticos que se plantean inicialmente. A partir de esta información se especificaran las
tecnologías y se procede a la consecución del proyecto.
17
Se desarrolló el método por el cual la interfaz se conecte al servidor externo y realice un proceso
inicial de envió y recepción de datos sin protocolo alguno para asegurar la conexión entre los
extremos de la transacción de datos.
Planteamiento básico acerca de los datos a enviar así como los campos del protocolo a utilizar en
los procesos de empaquetamiento y desempaquetamiento de información dinámica.
Seguimos con el desarrollo e implemento de una base para nuestro proyecto; Se implementarón
módulos recurrentes que tiene la terminal para comenzar el desarrollo (captura de texto,
impresión en pantalla, impresión de datos por papel).
El modelo para el desarrollo de software utilizado es un modelo iterativo y creciente en donde se
busca sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior incrementando
versiones entregables del sistema. Este modelo se apoya de un framework (entorno de trabajo) el
cual permite un desarrollo mas acelerado y ordenado. Igualmente el frameWork permite que el
código sea facilmente migrado a otras plataformas.
En este paso controló el comportamiento de todos los elementos que intervienen en la aplicación
independientemente de lo incorrecta y poco probable que pueda llegar a ser la situación. En
general se pretende multiplicar las comprobaciones que se realizan en todos lo módulos dejando
a la vista todos los posibles errores que pueden ocurrir, haciendo mas predecible el sistema y
disminuyendo el tiempo en la busqueda de soluciones. Este metodo se conoce como
programación defensiva.
En este punto se comprobó la funcionalidad de los procesos desarrollados con el fin de ajustar
posibles imperfecciones.
2. OBJETIVOS
2.1 Objetivo General
Diseñar e Implementar una aplicación sobre un sistema embebido que realice transacciones masivas
con un servidor externo según especificaciones del sistema.
2.2 Objetivos Específicos
Implementar módulo de descarga remota para evitar despliegues ineficientes al momento de
actualizar el aplicativo en los puntos de venta.
18
Diseñar e implementar un comprobante físico al momento de la venta que registra el TPV.
(ticket).
Desarrollar un manual de instrucciones para hacer un uso adecuado de la aplicación
implementada.
Realizar procesos de transferencia bidireccional de datos con un servidor externo.
3. MARCO TEÓRICO Y ESTADO DEL ARTE
3.1 Sistemas Embebidos
Los dispositivos FPGA o ARM permiten la implementación de todo el hardware y software de un
sistema digital en un circuito integrado configurable, permitiendo desarrollos conocidos como
Sistemas-en-Chip-Programable. Los sistemas embebidos pueden definirse como una combinación de
hardware y software de computadora, diseñado para tener una función específica. Por lo general los
sistemas embebidos se pueden programar directamente en el lenguaje ensamblador del
microcontrolador incorporado sobre el mismo o bien, utilizando algún compilador específico, suelen
utilizarse lenguajes como C y C++ (Escuela Politécnica Superior de Alcoy (España)., 2014).
Esta combinación de software y hardware puede ser reemplazada en muchos casos por un circuito
integrado que realice la misma tarea. Lo que señala que una de las ventajas de los sistemas embebidos
es su flexibilidad, ya que a la hora de realizar alguna modificación resulta mucho más sencillo
modificar unas líneas de código al software del sistema embebido que reemplazar todo el
circuito integrado.
ILUSTRACIÓN 1: TERMINAL PAX S90
19
Los sistemas embebidos suelen tener en una de sus partes una "computadora" con características
especiales conocida como microcontrolador que viene a ser el cerebro del sistema.
Este no es más que un microprocesador que incluye interfaces de entrada/salida en el mismo chip.
Normalmente estos sistemas poseen un interfaz externo para efectuar un monitoreo del estado y hacer
un diagnóstico del sistema, además cabe reseñar que el uso de sistemas embebidos en productos
complejos implica un desafío de la seguridad en TI para proteger la información contenida en el
sistema embebido y también la que es transmitida desde y hacia el dispositivo por redes privadas o
Internet. Por tanto cabe incluir funciones criptográficas, diseño de protocolos y consultoría en
análisis y verificación así como servicios de pruebas de seguridad y evaluaciones específicas
para sistemas embebidos (Prezi.com, 2014).
3.1.1 Sistema embebido a utilizar
Para el desarrollo del proyecto se ha utilizado por pedido del cliente una terminal de marca PAX
S90, utilizada ampliamente en el ámbito bancario en Centro América, debido a los altos
estándares de seguridad que maneja, al igual que la capacidad y calidad de comunicación que
ofrece el modem frente a otro tipo de terminales o sistemas. La Terminal POS móvil S90 de PAX
ha sido diseñada para ofrecer un rendimiento inalámbrico superior. Con múltiples opciones de
comunicación tales como solamente SIM o doble SIM GPRS, CDMA, WiFi y 3G, así como la gran
cantidad de memoria y de alta capacidad de Li-ion (iones de litio) batería recargable, la S90 es una
de las terminales móviles más populares con los comerciantes de hoy (PAX Technology Limited,
2013).
La S90 viene con un lector de tarjetas sin contacto incorporado, certificación PCI PTS 3.x y ofrece
transacciones seguras usando un procesador ARM 11 para soportar DUKPT, Master /Session, DES
y 3DES (PAX Technology Limited, 2013).
Procesador de alta velocidad ARM 11
Gran Capacidad en Memoria
Integrado opcional sin contacto
MasterCard Pay pass
Visa Pay Wave
Opcional Escáner de Código de barras
Conectividad USB & 3G
Gran capacidad en batería
GPRS (también doble SIM), CDMA, 3G
Especificaciones
Procesador:32-bit ARM 11
Comunicación: GPRS / CDMA /3G (WCDMA)
20
Módem (Opcional): Sync. (HDLC, hasta 9600bps), Async. (V.92, hasta 56kbps)
Físico: Longitud: 199mm, Ancho: 87mm, Altura: 61.5mm
Peso:504 g con batería
Batería: Li-ion (iones de litio), 1800mAh, 7.4V
Lector de Código de Barras (Opcional)
Scanner Código de Barras 1D
Certificaciones: PCI PTS3.x, EMV L1 & L2, MasterCard Pay Pass, Visa Pay Wave, EMV
Contactless L1.
Puertos Periféricos: 1 x RS232, 1 x mini USB (OTG), 1 x Line (Opcional), 1 x cargador de
energía.
Seguridad: PCI PTS 3.x aprobado, DUKPT, Master / Session, DES, 3DES, ANSI / ISO9564
formato 0, 1, 3, Algoritmo clave de PIN cifrado, ANSI 9.9 / X9.19 algoritmo MAC.
Temperatura Ambiente: 0°C a 50°C (32°F to 122°F), temperatura en operación -20°C a 70°C
(-4°F a 158°F), temperatura de almacenaje 10% a 93% humedad relativa, no condensado.
Lector Tarjeta sin Contacto (Opcional): MasterCard Pay Pass & Visa pay Wave 13.56 MHz,
ISO / IEC 14443 Tipo A / B, Mifare, Felica, NFC, 4 Indicadores RF.
Voltaje: Entrada: 100~240VAC, 50Hz / 60Hz, 1.0A, Salida: 9.5VDC, 4A.
Memoria: 192MB (128MB Flash, 64MB DDR).
Pantalla: 128 x 64 pixel LCD.
Teclado: 10 teclas alfanuméricas, 8 teclas de función, 4 teclas ATM, 1 tecla de
Encendido/Apagado.
Impresora: Impresora Térmica, velocidad: 18 líneas por segundo, ancho rollo de papel /
diámetro: 58 mm / 38 mm
Lector de Tarjeta Magnética: Pista 1 / 2 / 3, bidireccional.
Lector de Tarjeta Inteligente: EMV L1 y L2 Certificado.
Ranuras Tarjetas: 2 SAM, 1 SIM.
3.1.1.1 TPV (Terminal Punto de Venta)
Los TPV o mismos POS permiten la creación e impresión del tique de venta mediante las
referencias de productos. Se realizan diversas operaciones durante todo el proceso de venta, así como
cambios en el inventario. También generan diversos reportes que ayudan en la gestión del negocio.
Los TPV se componen de una parte hardware (dispositivos físicos) y otra de software (sistema
operativo y programa de gestión).
Principales Aplicaciones de los TPV:
Control de las unidades vendidas por cada operario, con la cual se le pueden aplicar medidas
de rendimiento.
Planificación automática de pedidos.
Análisis de ventas según el horario y la sección.
21
Control de los fallos externos a través de las devoluciones y el motivo de la devolución.
Asignación de diferentes niveles de privilegio para cada operador.
Los sistemas POS ofrecen mucha confiabilidad debido a que son un tipo de sistema embebido que no
está diseñado únicamente para oficinas, tal cual sucede con los ordenadores, en tanto que el POS ha
sido diseñado para un ambiente de punto de venta de alto tráfico. Son diferentes ambientes con
requerimientos diferentes.
3.2 Estándares de comunicación, sistemas embebidos
Una red de comunicación es la conexión entre dos o más dispositivos que pueden enviar y/o recibir
datos. Si un sistema embebido necesita comunicarse con otro sistema, ya sea una terminal, un
servidor u otro dispositivo embebido, estos deberán tener el mismo esquema de conexión. Para que la
comunicación sea satisfactoria deben contar con el mismo sistema de interconexión y el mismo
protocolo de red que permita tener una interoperabilidad.
Para construir aplicaciones que deban ejecutarse en red existen varios estándares, algunos de los
cuales se encuentran en la IEEE 802.
3.2.1 Comunicación GPRS (Global Packet Service)
El protocolo de comunicación GPRS es un estándar de comunicaciones inalámbrica basado en la
conmutación de paquetes de datos sobre la misma red GSM de la telefonía celular digital, con
modificaciones que implican una mayor velocidad y un mayor ancho de banda, está inmerso en la
tecnología de red 2.5G (GSM World, 2010).
Mientras que la red GSM transmite voz y tiene un sistema de mensajería con capacidad para 160
bytes por mensaje (el GSM-SMS), GPRS permite transmitir voz y datos de forma simultánea.
Otras capacidades de GPRS son la transferencia de archivos, la navegación en la Web, el correo
electrónico sin límites y funciones de localización geográfica (Digitalfotored, 2014).
Esta diversidad permite prever distintos tipos de terminales GPRS en función
de su utilidad: teléfonos móviles, con posibilidad de enviar mensajes con texto e imágenes;
agendas electrónicas, que permiten transmitir voz y datos; ordenadores de mano, tipo PDA;
ordenadores portátiles, que utilicen un teléfono GPRS para la conexión inalámbrica; o
dispositivos de comunicación con sistemas de navegación para automóviles (Digitalfotored,
2014).
22
ILUSTRACIÓN 2: ARQUITECTURA GPRS
Debido al icremento del número de usuarios de telefonía móvil y de usuarios de Internet era
inevitable que en algún momento ambos mundos se fusionasen (Voz y Datos). De allí surge la
tecnología GPRS.
El proceso de envió y recepción de datos se realiza por fases separadas mediante los denominados
nodos de soporte los cuales re-direccionan la información a puntos de una red interactiva, como
puentes informáticos, hasta llegar a su destino.
La conexión GPRS se realiza a través del protocolo PPP o punto a punto; Este servicio tiene como fin
proporcionar el direccionamiento único de recursos de red, estableciendo un enlace entre dos
dispositivos dinámica y temporalmente. El uso de este protocolo permite la asignación de IP
dinámicamente a un dispositivo. Los canales o sockets a través de los cuales se realiza esta
conexión, son generados dinámicamente, esto se hace con el fin de obtener siempre un canal de
comunicación libre y no entrar en conflictos en la ruta de acceso a la red (Universitat oberta de
Catalunya, 2013).
Para establecer la conexión con la red es necesario pasar por un proceso de verificación de datos y las
credenciales de acceso para el envio.
Cuando el dispositivo GPRS intenta conectarse a la red; lo que está realizando en realidad es un
proceso de negociación con el proveedor de la tarjeta de Módulo de Identificación del Suscriptor
(SIM) , en este proceso el dispositivo envía los datos correspondientes a la dirección IP a la cual se
solicita realizar el enlace en red, una vez el proveedor confirma todos los datos recibidos procede a
realizar el enlace tomando los datos recibidos y realiza un proceso de conexión por protocolo TCP/IP
con la dirección solicitada por el usuario GPRS, si el proceso de conexión es exitoso, el agente
proveedor funcionara, en adelante, como un “traductor” de protocolos; convirtiendo los datos que son
23
enviados por el MODEM GPRS en protocolo PPP, a datos enviados mediante protocolo TCP/IP
dirigidos a la dirección IP solicitada (uv.es, 2011).
Los datos solicitados por el agente proveedor son básicamente tres:
APN
Usuario GPRS
Contraseña GPRS
El APN (Access Point Name) es el nombre de punto de acceso el cual contiene una dirección IP a la
cual se puede conectar, un punto de configuración y una opción particular para el MODEM.
Estos APN corresponden a las redes públicas de estos operadores, sin embargo estos agentes poseen
APN privados los cuales corresponden a canales de comunicación de acceso restringido.
El protocolo de conexion al operador de telefonia movil exige un campo para contraseña y otro para
usuario, que en ocasiones por ser APN publico viajan vacios. Este tipo de datos nos brinda una
credencial de autenticación para obtener una direccion IP desde el punto de acceso al dispositivo
movil.
Este sistema de conexión posee una característica de cobro transaccional la cual se realiza por
cantidad de paquetes transmitidos y no cobro por tiempo de duración de la conexión, es decir, un
dispositivo puede estar conectado a la red pero no tendrá cobro alguno esta operación debido a que los
recursos utilizados por el GPRS son liberados en el instante en que se detiene la transacción de datos,
esto pasara siempre y cuando no exista un proceso de transmisión de datos en cualquier dirección por
el canal utilizado (uv.es, 2011).
Gracias a estas características, el servicio GPRS está dirigido principalmente a aplicaciones
interactivas las cuales presentan una densidad de transmisión de datos baja, lo cual disminuye los
recursos utilizados por el usuario, disminuyendo así los costos de operación de la aplicación; En
general este sistema aplica para cualquier proceso de transmisión de datos intermitente (uv.es, 2011).
A continuación se describen algunas de las principales características de la red GPRS:
Velocidad de transferencia de hasta 144 Kbps.
Conexión permanente.
Pago por cantidad de información transmitida, no por tiempo de conexión.
24
ILUSTRACIÓN 3: GPRS PROTOCOLO DE SEGUNDA GENERACIÓN
3.2.2 WCDMA(Acceso múltiple por división de código de banda ancha)
Este tipo de estandar hace parte de la 3er generación de telefonia movil (3G). Proporciona una mayor
eficiencia espectral, lo que permite proporcionar varios tipos de servicio en un mismo espacio
espectral (voz y datos con diferentes tasas binarias).
Se trata de una tecnología móvil que aumenta las tasas de transmisión de datos de los sistemas GSM
utilizando la interfaz aérea CDMA en lugar de TDMA (Acceso Múltiple por División de Tiempo).
Esta entrega velocidades de transmisión de datos mucho más altas en dispositivos
inalámbricos móviles y portátiles que las ofrecidas hasta el momento (puede alcanzar velocidades de
hasta 2 Mbps para voz, video, datos y transmisión de imágenes).
Tanto la tecnología WCDMA como la HSDPA pertenecen a la red 3G. La diferencia es que esta
última corresponde a la tecnología utilizada para efectuar la optimización en la descarga de datos a
través de esta red, por lo mismo puede que tenga variaciones (ENTEL, 2013).
WCDMA tiene aspectos tecnicos que lo hacen referente dentro del estandar 3G, por ejemplo soporta
protocolo IP, hace uso de la técnica de duplexación FDD, utiliza muy eficientemente el espectro de
radio disponible, mediante la reutilización de cada celda.
Los enlaces desde la red de acceso WCDMA y en el núcleo de red GSM utilizan un protocolo de
transmisión ATM de mini-celdas, conocido como Capa de Adaptación ATM 2 (AAL2).
WCDMA usa una tasa de chip de 4.096 Mcps. Entre los últimos estudios sobre WCDMA están:
Cancelación de Interferencia, Cancelación de Interferencia Gradual, Gerencia de Recurso Dinámico
en Sistemas Multimedia Inalámbricos, Técnicas de Codificación, entre otros (CAMPOS, 2009).
25
ILUSTRACIÓN 4. WCDMA VS CDMA
3.3 TCP/IP
Es un conjunto de reglas generales de diseño e implementación de protocolos de red específicos para
permitir que un equipo pueda comunicarse en una red. TCP/IP provee conectividad de extremo a
extremo especificando como los datos deberían ser formateados, direccionados, transmitidos,
enrutados y recibidos por el destinatario. Existen protocolos para los diferentes tipos de
servicios de comunicación entre equipos (Sanchez, 2010).
TCP/IP tiene cuatro capas de abstracción según se define en el RFC 1122. Esta arquitectura de capas
a menudo es comparada con el Modelo OSI de siete capas.
ILUSTRACIÓN 5: OSI VS TCP/IP
26
Caracteristicas:
Protocolo IP enrutado de la capa 3.
Funcionalidad extremo a extremo en la capa 4.
TCP/IP se usa como protocolo de acceso a Internet y para interconectar dispositivos de redes
corporativas.
El conjunto de protocolos TCP no solo incluye especificaciones de capa 3 y 4, sino también
especificaciones para aplicaciones comunes, como correo electrónico, emulación de terminal
y transferencia de archivos.
Transferencia de archivos: TFTP, FTP, NFS.
Correo electrónico: SMTP.
Login remoto: TELNET Y RELOGIN.
Administración de red: SNMP.
Administración de nombres: DNS.
Este modelo se creó a principios de la década de los setenta y se conoce con el nombre de modelo de
Internet. Define cuatro categorías de funciones que deben tener lugar para que las comunicaciones
sean exitosas.
Un proceso completo de comunicación incluye estos pasos:
1. Creación de datos a nivel de la capa de aplicación del dispositivo final origen.
2. Segmentación y encapsulación de datos cuando pasan por la stack de protocolos en el dispositivo
final de origen.
3. Generación de los datos sobre el medio en la capa de acceso a la red de la stack.
4. Transporte de los datos a través de la red de internet, que consiste de los medios y de cualquier
dispositivo intermediario.
5. Recepción de los datos en la capa de acceso a la red del dispositivo final de destino.
6. Desencapsulación y rearmado de los datos cuando pasan por la stack en el dispositivo final.
7. Traspaso de estos datos a la aplicación de destino en la capa de aplicación del dispositivo final de
destino (Cisco Systems, Inc, 2007).
Las funciones de las diferentes capas son las siguientes:
Capa de acceso a la red: Específica la forma en la que los datos deben enrutarse, sea cual sea el
tipo de red utilizado.
Capa de Internet: Es responsable de proporcionar el paquete de datos (datagrama);
Capa de transporte: Brinda los datos de enrutamiento, junto con los mecanismos que permiten
conocer el estado de la transmisión.
Capa de aplicación: incorpora aplicaciones de red estándar (Telnet, SMTP, FTP, etc.).
27
ILUSTRACIÓN 6: CABECERA TCP
Puerto origen: Número de puerto que llama (16 bits).
Puerto destino: Número del puerto al que se llama (16 bits).
Número de secuencia: Número usado para garantizar la corrección en la secuencia de la llegada de
datos(32 bits).
Número de acuse de recibo: Siguiente octeto TCP esperado(4 bits).
Reservado: Fijado en 0(6 bits).
Bits de código: Funciones de control, como el establecimiento y la finalización de una sesión(6 bits).
Ventana: Número de octetos que el dispositivo espera aceptar (16) bits.
Suma de comprobación: Suma de comprobación de cabecera y campos de datos (16 bits).
Urgente: Indica el final de los datos urgentes(16 bits).
Opciones: Algo ya definido, tamaño máximo del segmento TCP(0 a 32 bits, si hay)
3.3.1 Puertos TCP/IP
Culaquier tipo de proceso o desarrollo de software con conexion TCP/IP se identifica a sí mismo a la
familia de protocolos TCP/IP por uno o más puertos. Un puerto es un número de 16 bits, usado por el
28
protocolo HOST TO HOST para identificar a qué protocolo de más alto nivel o programa de
aplicación (proceso) debe entregar los mensajes de entrada (Dunkels, 2006).
El puerto es una numeración lógica que se asigna a las conexiones, tanto en el origen como en el
destino. No tiene ninguna significación física.
En una URL (Universal Resource Locator) los puertos se denotan con ':' a continuación del nombre de
la máquina, por ejemplo http://www.alerta-antivirus.es:80/index.html quiere decir pedir el
documento 'index.html' mediante http conectándose al puerto 80 de este servidor. Como 80 es el
puerto por defecto para http se puede omitir (Sitiosargentina.com, 2009).
Las aplicaciones de tipo cliente, como un navegador web, un cliente de correo electrónico, o de chat
(IRC) no necesitan tener puertos abiertos.
Es recomendable el funcionamiento sigiloso de los puesrtos para no dar facilidades a los hackers.
Algunos hackers hacen escaneos aleatorios de IPs y puertos por Internet, intentando identificar las
características de los sistemas conectados, y creando bases de datos con estas. Cuando se descubre
una vulnerabilidad, están en disposición de atacar rápidamente a las máquinas que se sabe que son del
tipo vulnerable.
Un puerto de red es una interfaz para comunicarse con un programa a través de una red. Un puerto
suele estar numerado. La implementación del protocolo en el destino utilizará ese número para
decidir a qué programa entregará los datos recibidos. Esta asignación de puertos permite a una
máquina establecer simultáneamente diversas conexiones con máquinas distintas, ya que todos los
paquetes que se reciben tienen la misma dirección, pero van dirigidos a puertos diferentes (Zator.com,
2011).
Los números de puerto se indican mediante una palabra, 2 bytes (16 bits), por lo que existen 65535.
Aunque podemos usar cualquiera de ellos para cualquier protocolo, existe una entidad, la IANA
(Internet Assigned Numbers Authority), encargada de su asignación, la cual creó tres categorías:
Los puertos inferiores al 1024 son puertos reservados para el sistema operativo y usados por
"protocolos bien conocidos". Si queremos usar uno de estos puertos tendremos que arrancar el
servicio que los use teniendo permisos de administrador.
Los comprendidos entre 1024 (0400 en hexadecimal) y 49151 (BFFF en hexadecimal) son
denominados "registrados" y pueden ser usados por cualquier aplicación. Existe una lista
publica en la web del IANA donde se puede ver qué protocolo usa cada uno de ellos
Los comprendidos entre los números 49152 (C000 en hexadecimal) y 65535 (FFFF en
hexadecimal) son denominados dinámicos o privados, porque son los usados por el sistema
operativo cuando una aplicación tiene que conectarse a un servidor y por tanto necesita un
puerto por donde salir (L.Silva, 2011).
29
Como algunos programas de más alto nivel son protocolos por sí mismos, estandarizados en la
familia de protocolos TCP/IP, tales como telnet y ftp, usan el mismo número de puerto en todas las
realizaciones de TCP/IP. Aquellos números de puerto "asignados" se denominan puertos
bien-conocidos y las aplicaciones estándares servicios bien-conocidos (Universidad de Oviedo Ingeniería de sistemas y automatica, 2006).
La confusión debida a que dos aplicaciones diferentes intentan usar los mismos números de puerto
sobre un host se evita escribiendo esas aplicaciones para pedir un puerto TCP/IP disponible. Puesto
que este número de puerto se asigna dinámicamente, debe diferir de una invocación de una aplicación
a la próxima.
Algunos de los puertos conocidos más utilizados son :
TABLA 1: ALGUNOS PUERTOS CONOCIDOS
3.3.2 Sockets
Por terminologia un socket es un tipo especial de manejador de fichero que utiliza un proceso para
pedir servicios de red al sistema operativo. Una dirección de socket es la tripleta: {protocolo,
dirección-local, proceso-local}.En la familia TCP/IP, por ejemplo: {tcp, 193.44.234.3, 12345}
Una conexión es el enlace de comunicación entre dos procesos, una asociación es la quíntupla que
especifica completamente los dos procesos que comprende una conexión:
{protocolo, dirección-local, proceso-local, dirección-externa, proceso-externo}
En la familia TCP/IP, por ejemplo:
{tcp, 193.44.234.3, 1500, 193.44.234.5, 21}
30
Los sockets son puntos de comunicación entre procesos que permiten que un desarrollo se comunique
con otro desarrollo, incluso estando estos en distintas máquinas. Esta característica de
interconectividad entre máquinas hace que el concepto de socket nos sirva de gran utilidad. Esta
interfaz de comunicaciones es una de las distribuciones de Berkeley al sistema UNIX,
implementándose las utilidades de interconectividad de este Sistema Operativo ( rlogin, telnet, ftp,
etc. ) usando sockets (Barranco, 1996).
Un socket es al sistema de comunicación entre ordenadores lo que un buzón o un teléfono es al
sistema de comunicación entre personas: un punto de comunicación entre dos agentes por el cual se
puede emitir o recibir información. La forma de referenciar un socket por los procesos implicados es
mediante un descriptor del mismo tipo que el utilizado para referenciar ficheros.
La comunicación entre procesos a través de sockets se basa en la filosofía CLIENTE-SERVIDOR, un
proceso en esta comunicación actuará de servidor creando un socket cuyo nombre conocerá el
proceso cliente, el cual podrá "hablar" con el servidor a través de la conexión con dicho socket
nombrado (Barranco, 1996).
Tipos de sockets:
Tipo SOCK_DGRAM: sockets para comunicaciones en modo no conectado, con envío de
datagramas de tamaño limitado ( tipo telegrama ). En dominios Internet como la que nos
ocupa el protocolo del nivel de transporte sobre el que se basa es el UDP.
Tipo SOCK_STREAM: para comunicaciones fiables en modo conectado, de dos vías y con
tamaño variable de los mensajes de datos. Por debajo, en dominios Internet, subyace el
protocolo TCP.
Tipo SOCK_RAW:
red ).
Tipo SOCK_SEQPACKET: tiene las características del SOCK_STREAM pero además el
tamaño de los mensajes es fijo (Barranco, 1996).
permite el acceso a protocolos de más bajo nivel como el IP ( nivel de
3.4 PPP ( Point to Point Protocol )
Generalmente a través de una línea telefónica pueden comunicarse un máximo de dos equipos
mediante un módem, al igual que resulta imposible llamar a dos personas simultáneamente utilizando
la misma línea telefónica. Esto se denomina conexión punto a punto, es decir, una conexión entre dos
equipos reducida a su expresión más sencilla: no es necesario compartir la línea con diversos equipos,
uno habla y el otro responde alternativamente (Kioskea, 2013).
31
Se han desarrollado diversos protocolos de módem. los primeros permitían una simple transmisión de
datos entre dos equipos. Luego, algunos de ellos contaron con control de errores y, con el crecimiento
de Internet, también contaron con la capacidad de asignar direcciones a equipos. De esta manera,
existen actualmente dos protocolos de módem principales:
SLIP: un protocolo antiguo, con pocos controles.
PPP: El protocolo más utilizado para acceder a Internet mediante un módem. Permite asignar
direcciones a equipos.
El Protocolo punto a punto es un protocolo mucho más desarrollado que SLIP (por ello lo está
reemplazando), en la medida en que transfiere datos adicionales más adaptados a la transmisión de
datos a través de Internet (la adición de datos en una trama se debe principalmente al aumento del
ancho de banda).
En realidad, PPP es un conjunto de tres protocolos:
un protocolo de encapsulación de datagramas, un protocolo LCP, Protocolo de control de vínculos,
que permite probar y configurar la comunicación
Los datos encapsulados en una trama PPP se denominan paquetes. Estos paquetes generalmente son
datagramas, pero también pueden ser diferentes (de allí la designación específica de paquete en lugar
de datagrama). Por lo tanto, un campo de la trama se reserva para el tipo de protocolo al que el
paquete pertenece. Así es una trama PPP:
ILUSTRACIÓN 7: POINT TO POINT PROTOCOL
Los datos de relleno se utilizan para adaptar la longitud de la trama para ciertos protocolos.
A continuación se indica cómo se lleva a cabo una sesión PPP (desde el comienzo hasta el fin):
Una vez que se cuenta con conexión se envía un paquete LCP.
En el caso de una solicitud de autenticación del servidor, se puede enviar un paquete relacionado con
un protocolo de autenticación (PAP, Protocolo de autenticación de contraseña, o CHAP, Protocolo de
autenticación por desafío mutuo o Kerberos).
Una vez que se establece la comunicación, PPP envía información de configuración mediante el
protocolo NCP.
32
Los datagramas que se van a enviar se transmiten como paquetes. En el momento de la desconexión,
se envía un paquete LCP para finalizar la sesión.
La mayoría de las personas que no cuentan con líneas (cable o Ethernet) directamente conectadas a
Internet deben utilizar líneas telefónicas (la red más utilizada) para conectarse. La conexión se realiza
mediante un módem, un dispositivo que puede convertir datos digitales de un equipo en señales
analógicas (que pueden circular por líneas telefónicas mediante amplitud modulada o frecuencia
modulada, de la misma manera que la voz cuando se utiliza el teléfono) (Kioskea, 2013).
Si se tiene en cuenta que sólo comunican dos equipos y que la velocidad de la línea telefónica es lenta
en comparación con la de una red local, es necesario utilizar un protocolo que permita la
comunicación estándar entre diferentes equipos con módem, para no sobrecargar la línea telefónica,
se denominan protocolos de módem.
ILUSTRACIÓN 8: SISTEMA PUNTO A PUNTO
3.5 FTP (File Transfer Protocol)
Es un sistema de reglas de comunicación que permite que dos dispositivos se comuniquen entre sí
independientemente del sistema operativo que utilicen, haciendo posible enviar información o
descargar archivos específicos.
El protocolo de transferencia de archivos también proporciona características para controlar el acceso
de los usuarios. Cuando un usuario solicita la transferencia de un fichero, FTP establece una conexión
TCP con el sistema destino para el intercambio de mensajes de control. A través de esta conexión se
puede transmitir el identificador y la contraseña del usuario, y el usuario puede especificar el fichero
y las acciones sobre él deseadas (Crespo Martínez & Candelas Herías, 1998).
33
ILUSTRACIÓN 9: FTP
Una vez que se aprueba la transferencia del fichero, se establece una segunda conexión TCP para la
transferencia de datos. El fichero se transmite a través de esa conexión de datos, sin información
suplementaria o cualquier cabecera de la capa de aplicación. Cuando la transferencia se completa, el
control de la conexión se utiliza para indicar el final y la posibilidad de aceptar nuevas órdenes de
transferencia (Crespo Martínez & Candelas Herías, 1998).
3.6 HTTP
El Protocolo de Transferencia de HiperTexto es un sencillo protocolo cliente-servidor que articula los
intercambios de información entre los clientes Web y los servidores HTTP. La especificación
completa del protocolo HTTP 1/0 está recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee,
atendiendo a las necesidades de un sistema global de distribución de información como el World
Wide Web (Herramienta web para la enseñanza de comunicación, 2012).
Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCP/IP,
y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX.
Se trata de un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y
espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el
protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de
errores.
HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con
un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje
similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden
adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, fichero
multimedia o aplicación CGI) es conocido por su URL (Herramienta web para la enseñanza de
comunicación, 2012).
34
3.7 Protocolo ISO8583
ISO-8583 es un protocolo transaccional de empaquetamiento y transferencia de datos
propuesto para sistemas que intercambian transacciones electrónicas; este protocolo está orientado a
todo tipo de transacciones financieras en las cuales se vean implicadas tarjetas de crédito o cualquier
tarjeta de pago electrónico, sin embargo el Standard ISO-8583 se ve involucrado actualmente en todo
tipo de transacciones financieras que tengan o no involucrada una tarjeta de cualquier tipo para su
realización.
ISO-8583 consta de dos estructuras básicas, la cabecera y los datos de aplicación.
En la cabecera encontramos el tamaño de los datos transmitidos y el
de transporte de datos de la Unidad (TPDU).
La estructura correspondiente
fundamentales:
•
•
•
a
los
datos de aplicación consta de
Protocolo
tres partes
El MTI
El Bitmap
Los elementos de datos
El tipo de mensaje (MTI) consta de cuatro (4) dígitos y se utiliza para definir el tipo de mensaje de la
transacción. El primero y segundo dígito identifica la clase de mensaje. El tercer y cuarto dígito se
utiliza para identificar la función del mensaje y el modo de transmisión.
Definición del tipo de mensaje:
para los dígitos 1 y 2:
01
02
03
04
05
06
08
Autorización
Financiera
Archivo de actualización / transferencia
Reverso
Reconciliación de control
Administrativa
Gestión de red
Para los dígitos 3 y 4
00 Solicitud interactiva
10 Respuesta interactiva
35
20 Asesoramiento no interactivo
Algunos ejemplos de tipo de mensaje usualmente utilizados son:
0100 solicitud de autorización
0110 respuesta de solicitud de autorización
0200 solicitud de trasferencias financieras
0210 Respuesta de solicitud de trasferencias financieras
0400 solicitud de reverso
0410 respuesta de solicitud de reverso
El Bitmap o mapa de bits es un conjunto de 8 bytes o 16 caracteres donde se asigna a cada elemento
de los datos un indicador de posición en un campo de control. Este nos indica cuales son los campos
que deben ser leídos en la operación transaccional. La presencia de un elemento de datos en un
mensaje específico se indica con un (1), en el asigna la posición, la ausencia de un elemento de datos
se indica con un cero (0) en la posición asignada. Un mapa de bits consiste en 64 bits
contados de
izquierda a derecha empezando por el BIT uno (Hypercom, 2002).
Los elementos de datos son una serie de campos preestablecidos por el protocolo ISO8583 los cuales varían entre sí en cuanto a tamaño y tipo de datos soportados por cada uno, cada
campo posee un nombre, un formato y un tamaño predeterminado (Hypercom, 2002).
A continuación se muestra una tabla con la descripción de cada uno de los campos involucrados en el
protocolo ISO 8583.
TABLA 2: CAMPOS ISO 8583
36
ATRIBUTOS: a (caracteres alfabéticos), n (datos numéricos), s (caracteres especiales), an-as--ns-ans
combinación de los anteriores respectivamente, b (dato en formato binario), z (dato recibido de la
banda magnética).
Algunos ejemplos de campos establecidos en el protocolo ISO-8583 son:
Campo 3. processing code (código de procesamiento):
El código de procesamiento se utiliza en conjunción con el tipo de mensaje para definir el tipo de
transacción que se está enviado por el Terminal en el servidor.
Este campo tiene un tamaño de 6 caracteres estáticos los cuales deben ser únicamente de tipo
numérico, es decir, de 0 a 9. Ejemplo:
[92 00 00]
Campo 41. Terminal ID (identificación de la Terminal):
Este es el código de identificación único del dispositivo, con este código se identifica por parte del
servidor cual es el Terminal que está realizando la transacción.
Campo para caracteres alfanuméricos y especiales y tiene una longitud de 8 caracteres. Ejemplo:
[3f0010278]
Campo 60. uso privado:
No todos los campos tienen longitud específica, existen algunos como el campo 60 los cuales tienen
una longitud variable; Los campos de uso privado se utilizan con el fin de enviar datos opcionales en
la transmisión de datos, estos datos son propios de cada transacción y se pueden enviar a
preferencia de la Terminal.
El campo 60 tiene longitud variable y soporta caracteres alfanuméricos y especiales, el tamaño
máximo de este campo es de 999 Bytes.
Cuando se utilizan campos de longitud variable usualmente se envía en las dos primeras posiciones
del campo la longitud en formato BCD con el fin de indicar al servidor cuantos Bytes se envían en
ese campo especifico. Ejemplo: [00 05 38 33 33 39 37]
37
3.8 Compresión y descompresión de datos
3.8.1
¿Para que se comprimen datos?
Actualmente, el poder de procesamiento de los procesadores se incrementa más rápido que la
capacidad de almacenamiento y es más veloz que los anchos de banda de las redes, porque estos
últimos requieren cambios enormes en las infraestructuras de telecomunicación.
Por lo tanto, para compensar esto, es más común el procedimiento de reducir el tamaño de los datos al
explotar el poder de procesamiento de los procesadores, que incrementar la capacidad de
almacenamiento y de transmisión de datos (CCM, 2014).
3.8.2
¿Que es la compresión de datos?
La compresión consiste en reducir el tamaño físico de bloques de información. Un compresor se vale
de un algoritmo que se utiliza para optimizar los datos al tener en cuenta consideraciones apropiadas
para el tipo de datos que se van a comprimir. Por lo tanto, es necesario un descompresor para
reconstruir los datos originales por medio de un algoritmo opuesto al que se utiliza para la compresión
(CCM, 2014).
La siguiente imagen muestra los pasos de compresión y descompresón de un archivo.
ILUSTRACIÓN 10: COMPRESIÓN Y DESCOMPRESIÓN DE ARCHIVOS
3.8.3
Tipos de compresión
La compresión física actúa directamente sobre los datos; por lo tanto, es cuestión de
almacenar los datos repetidos de un patrón de bits a otro.
La compresión lógica, por otro lado, se lleva a cabo por razonamiento lógico al sustituir esta
información por información equivalente.
38
3.8.4
Métodos de compresión
En el caso de la compresión simétrica (Ilustración 11), se utiliza el mismo método para
comprimir y para descomprimir los datos. Por lo tanto, cada operación requiere la misma
cantidad de trabajo. En general, se utiliza este tipo de compresión en la transmisión de datos.
ILUSTRACIÓN 11: COMPRESÍON SIMÉTRICA
La compresión asimétrica requiere más trabajo para una de las dos operaciones. Es frecuente
buscar algoritmos para los cuales la compresión es más lenta que la descompresión. Los
algoritmos que realizan la compresión de datos con más rapidez que la descompresión pueden
ser necesarios cuando se trabaja con archivos de datos a los cuales se accede con muy poca
frecuencia (por razones de seguridad, por ejemplo), ya que esto crea archivos compactos
(CCM, 2014).
3.8.5 Compresión con perdida de datos
La comprensión con perdida es un método de compresión de datos que permite comprimir datos que
al ser descomprimidos no son exactamente como los originales. Por lo general, la compresión con
pérdida de datos se utiliza en la compresión de datos multimediales. Como este tipo de compresión
elimina información que está contenida en los datos que se van a comprimir, por lo general se habla
de métodos de compresión irreversible (CCM, 2014).
Cuando se habla de imágenes, sonido y video, suele llamarse también compresión con pérdida de
calidad, porque es la calidad lo que se está viendo afectada. La compresión con pérdida de datos suele
lograr bastante mayor compresión que la compresión sin pérdida. Esto significa que el resultado
ocupará menos bytes de almacenamiento. Por ejemplo, la compresión de audio puede llegar a
permitir que el archivo ocupe una décima parte del original sin comprimir y prácticamente el oído
humano no capta la diferencia. Para las imágenes, también puede lograrse una alta tasa de compresión,
pero es más evidente en el resultado final. En tanto en videos, la compresión con pérdida puede lograr
que ocupe 1/300 parte del original (CCM, 2014).
39
Los métodos de compresión con pérdida de datos se basan en las percepciones humanas para lograr su
cometido. El objetivo es lograr que las personas no perciban el cambio del original. Por ejemplo, los
archivos comprimidos en MP3, logran una calidad de audio excepcional y gran compresión. En tanto,
las imágenes JPG, logran una muy buena compresión, permitiendo seleccionar un número de
compresión del 0 al 100. El número más alto permite mayor calidad, pero el archivo final ocupa más
espacio. Una calidad aceptable es 80 (CCM, 2014).
3.8.6 Compresión sin perdida de datos
Tipo de algoritmos de compresión de datos que permite que la información original sea perfectamente
recuperada a partir de datos comprimidos. Cuando se comprimen imágenes, videos o sonidos sin
pérdida, suele referirse como "compresión sin pérdida de calidad". La compresión sin pérdida de
datos, es utilizada para comprimir archivos o información que contienen datos que no pueden ser
degradados o perdidos, como pueden ser documentos de texto, archivos ejecutables, etc. (CCM,
2014).
En principio, los algoritmos de compresión sin pérdida de datos pueden ser usados para comprimir
cualquier tipo de dato. Algunos tipos de datos no permitirán demasiada compresión (logrando que la
compresión sea similar en tamaño en bytes que el archivo original) y otros lograrán una muy buena
compresión. Por lo general, los archivos de texto pueden ser muy comprimidos, en cambio archivos
de audio, no logran una significativa compresión (CCM, 2014).
3.8.7 Formato 7z
7z es un formato de archivo de alta relación de compresión, es el formato por defecto del archivador
7-Zip.
Las principales características del formato 7z son:
Arquitectura abierta.
Alta relación de compresión.
Fuerte cifrado AES-256.
Capacidad de utilizar cualquier compresión, conversión o método de cifrado.
Apoyo a los archivos con tamaños de hasta 16.000.000.000 GB.
Nombres de archivo Unicode (7 Zip, 2012).
Compresión sólida
Archivo de compresión de cabeceras
7z cuenta con una arquitectura abierta, por lo tanto puede soportar nuevos métodos de compresión.
Los métodos integrados actualmente son los mostrados en la siguiente tabla.
40
TABLA 3: METODOS DE COMPRESIÓN INTEGRADOS A 7Z
3.8.8 Algoritmo LZMA
LZMA es el método por defecto y general de la compresión del formato 7z. Las características
principales del método de LZMA:
Alto cociente de compresión.
Tamaño variable del diccionario (hasta 4 GB).
Velocidad de compresión: cerca de 1 MB/s en la CPU de 2 GH.
Descompresión de velocidad: cerca de 10-20 MB/s en la CPU de 2 GH.
Pequeños requisitos de memoria para descomprimir (dependa de tamaño del diccionario).
Pequeño tamaño de código para descomprimir: cerca de 5 KB.
Apoyo multi-threading y el hyper-threading de P4 (7 Zip, 2012).
El algoritmo de compresión de LZMA es muy conveniente para los usos encajados. LZMA se lanza
de conformidad con el GNU LGPL.
7-Zip también apoya la encripción con el algoritmo AES-256. Este algoritmo utiliza una llave de
cifrado con la longitud de 256 bits. Para crear la llave en 7-Zip se utiliza la función de la derivación
basada en el algoritmo hash SHA-256. Una función de derivación principal produce una llave
derivada de la contraseña del texto definida por el usuario. Para aumentar el coste de la búsqueda
exhaustiva para las contraseñas 7-Zip utiliza el número grande de iteraciones para producir llave de
cifrado de contraseña del texto (7 Zip, 2012).
3.9 Apuestas en República Dominicana
En República Dominicana a finales de la década de los 80 se conoció el concepto de Bancas
Deportivas como una alternativa de entretenimiento y apuesta, que al mismo tiempo generaba
empleos de manera directa e indirectamente. Este concepto fue evolucionando, debido a que en sus
41
inicios los medios de tecnología de información y control y comunicación avanzada, creaba una
serie de pérdidas financieras, que poco a poco fue mejorando. Todo este proceso creó las llamadas
bancas de apuestas, enlazadas a través de la red de tecnología de comunicación que no sólo se
concentran en apuestas deportivas, sino ofrecen servicios de Lotería, Pale, Juegos vía satélite, entre
otros. Estos enlaces de Tecnología de Información usan actualmente en poca
proporción sistemas On-line con líneas dedicadas conectadas a servidores en muchas partes
de Estados Unidos de donde se obtiene la información de las jugadas así como
también datos estadísticos de jugadas y probabilidades (Castillo, 2014).
Aun con todo el avance actual y las facilidades que ofrece el mercado de las telecomunicaciones, las
bancas de apuestas se mantienen muy pasivas en cuanto a cambios en su infraestructura. Alrededor
del 85% de estas usan sistemas de base de datos de Cobol y son compilados en DOS o Xenix, que son
formatos de caracteres ASCII en las pantallas, comunicación limitada a 1.2 Kbps, alta vulnerabilidad
del hardware, alta posibilidad de fraude y perdida en los Impuestos anuales del país (Castillo, 2014).
En República Dominicana existen variedad de loterías en cuanto a juegos de azar respecta, a
continuación se conocerá puntualmente cada una de las loterías y los juegos que ostentan, los cuales
serán parte vital del desarrollo que se lleva a cabo:
En República Dominicana existen 4 Loterías, las cuales tienen varios premios diarios o semanales,
unas ofrecen premios acumulativos y otras tan solo premios dependiendo la cantidad de dinero o
el tipo de juego que hayas jugado.
La Lotería Nacional: Esta es la principal, ya que pertenece al Gobierno de la República Dominicana
y tan sólo cuenta con un tipo de premio.
Lotería Leidsa: Esta es una de las nuevas modalidades y vino a ser la primera en este ramo, la cual
ofrece premios acumulativos, así como otras diversidades de juego, con lo que brinda la oportunidad
a los jugadores de ganar dependiendo su interés, entre sus juegos están: Loto Millonario, Quiniela
Palé, Loto más, Súper Palé, Pega 3, Loto Pool, Súper Kinto TV y el Súper Bingo.
Lotería Loteka: Esta ha venido con fuerte competencia para Leidsa, ya que básicamente es en esa
misma modalidad de premiaciones, entre los que se cuentan: Migra Tripleta Exacta, Mega Tripleta,
Mega Líneas, Mega Palé, Mega Quiniela, Mega Lotto.
Loto Real: Otra denominación al igual que las dos anteriores y entre sus atractivos están: Súper Loto,
Loto Real, Quiniela Real, Súper Palé Real, Pega Real.
A continuación se encuentran los juegos que inicialmente se han contemplado para el desarrollo. Al
ser un desarrollo de mensajería dinámica, la inicialización de este tipo juegos podrá realizarse sin
42
inconveniente alguno, y provocará que también se puedan inicializar otro tipo de juegos indicando
cada uno de los parámetros de inicialización requeridos en la mensajería.
Quiniela
En este tipo de juego se debe elegir un número del 1 al 100 y tiene tres oportunidades de ganar, se
juega inicialmente con 2 dígitos. Puede ganar con cualquiera de los tres números que resulten
ganadores del sorteo. Por cada RD$1.00 apostado gana:
Primer Premio: RS$60.00
Segundo Premio: RD$10.00
Tercer Premio: RD$5.00
Palé
Para este juego se debe elegir 2 (dos) números del 1 al 100 y tiene tres oportunidades de ganar, se
juega inicialmente con 4 dígitos (2 números de 2 dígitos), se puede ganar combinando dos números
cualquiera de los tres números que resulten ganadores en el sorteo sin importar el orden en que se elija
los números. Por cada RD$1.00 apostado las siguientes combinaciones ganan:
Primer Premio y Segundo Premio: RD$1000.00
Primer Premio y Tercer Premio: RD$1000.00
Segundo Premio y Tercer Premio: RD$100.00
Tripleta
Debe elegir 3 (tres) números de 2 dígitos y tiene dos formas de ganar: Primero si acierta los tres
números que resulten ganadores en el sorteo sin importar el orden que se hayan elegido, y también
acertando dos números de los tres números que resulten ganadores sin importar el orden de la
selección. Por cada RD$1.00 apostado las siguientes combinaciones ganan:
Por acertar los Tres Premios: RD$20,000.00
Por acertar Dos de los Tres Premios: RD$100.00
Súper Pale
Debe elegir el numero ganador del primer premio de por lo menos dos de las loterías que se ofrecen
(LOTEKA, LEIDSA, Lotería Nacional y Lotería Real). Se gana si acierta el primer premio de las
loterías escogidas, se juega con 4 dígitos al igual que el Palé (2 números de 2 dígitos). Por cada
RD$1.00 apostado gana:
Por acertar el primer premio de ambas loterías: RD$3,000.00
43
El súper pale resulta ganador si los números jugados resultan ganadores del premio mayor de cada
uno en una de las loterías de las combinadas.
Pérez Abreu es, desde hace más de 20 años, uno de los principales proveedores en República
Dominica de software para la administración de bancas de apuestas. La empresa tenía funcionando
una aplicación para registrar apuestas de lotería bajo el esquema de trabajo online contra un servidor
que tenía un grave inconveniente de seguridad. Debido a que en República Dominicana las
conexiones de Internet no son muy consistentes, debieron incorporar un mecanismo por el cual, al
cortarse la comunicación con el servidor se permitiera acumular apuestas localmente y, en el
momento de restaurarse la comunicación, se enviarían estas apuestas al servidor (Sitepro, 2009).
La firma descubrió que ‘casualmente’ en algunas agencias se cortaba habitualmente la comunicación
con el servidor unos 5 o 10 minutos antes de que empezaran los sorteos de la lotería local. Y luego se
recuperaba la conexión pocos minutos luego de que el sorteo había comenzado. Dándose la ‘fortuna’
que, entre las jugadas que se habían realizado unos minutos antes de que empiece el sorteo, aparecían
apuestas a los primeros números sorteados antes de recuperarse la conexión (Sitepro, 2009).
Francis Pérez y Jorge Gutiérrez, de Pérez Abreu, explican: ‘Descubrimos que algunos operadores
avivados desconectaban el cable de internet a propósito, antes de empezar el sorteo atrasaban el reloj
del equipo recaudador de apuestas, ingresaban apuestas con los números favorecidos al principio del
sorteo, y luego volvían el reloj a la hora correcta, se conectaban a internet nuevamente y de esta forma
se transmitían las jugadas supuestamente acumuladas antes del inicio del sorteo y que no pudieron ser
enviadas por el corte de la conexión de internet (Sitepro, 2009).
Debido a esto el sistema de apuestas instaurado no permite de ninguna manera cambiar la hora en el
sistema POS, este es uno de los principales problemas que se plantea en este sistema de apuestas.
3.10 Descripción y definición de la red a utilizar.
3.10.1 Definición del método de transmisión de datos cliente-servidor.
La transferencia de archivos de un Host a un cliente tipo terminal punto de venta, puede ser
desarrollada utilizando cualquier tipo de protocolo de comunicación de alto nivel siendo el FTP,
HTTP y TCP/IP las principales opciones.
FTP
Ventajas
Presenta un aprovechamiento del ancho de banda optimo, esto se debe a que el protocolo está
orientado al envió de información del archivo con un gasto mínimo de bytes usados por el
protocolo.
44
Posee un sistema de autenticación de usuario con el que se proporcionan permisos a los
clientes
En su variación a FTPS se logra proporcionar un nivel de seguridad más alto a la información
transferida la cual estará encriptada bajo el protocolo SSL.
Desventajas
Es insuficiente para ambientes de trabajo que requieren seguridad y auditorias.
Los servidores pueden ser atacados desde distintos equipos para inundarlos. Esto detiene los
procesos y afecta significativamente la productividad.
No es posible reanudar una transferencia de información que ha sido interrumpida.
HTTP
Ventajas
El proceso de carga del archivo en el servidor es sencillo.
Es posible implementar algoritmos de reanudación de descarga de información que han sido
interrumpidos
En su variación a HTTPS se logra proporcionar un nivel de seguridad más alto a la
información encriptada bajo el protocolo SSL.
Desventajas
El ancho de banda se desperdicia debido a la implementación de formularios HTML.
La transferencia de información innecesaria provoca tiempos de ejecución del sistema más
elevados.
El gasto de datos es elevado debido a que el protocolo posee demasiadas etiquetas o bytes
innecesarios en la transmisión y la recepción.
Es descartado el uso de HTTP para el sistema debido al incremento en el tiempo de ejecución del
sistema y al uso de formularios HTML que implican un consumo innecesario del ancho de banda,
igualmente el FTP no puede reanudar descargas que se detuvieron en una parte del proceso, por ello
se hará por TCP/IP, utilizando ISO 8583 en la transmisión de cada paquete.
3.11 Estado del arte
Teniendo en cuenta un estudio previo frente a desarrollos electrónicos enfocados plenamente en
las telecomunicaciones y entornos de programación, se encontró algunos desarrollos a nivel
internacional y a nivel nacional, que se explican a continuación:
45
3.11.1 Proyecto 1:
Domótica para Sistemas Embebidos – Juan Manual Picerno, ken Tenzer, Universidad de la
Republica, Uruguay.
Se propuso una API que permite la programación de aplicaciones con un alto grado de portabilidad.
La solución propuesta está basada en una plataforma con arquitectura orientada a servicios
desarrollada en JAVA llamada OSGi. La API permite interactuar con distintas tecnologías de forma
homogénea, los cuales incluso pueden estar distribuidos entre varios sistemas. Para mostrar su
aplicabilidad de desarrollo se trabajó un prototipo para la automatización de un baño en una
plataforma con recursos limitados, usando el proyecto USbAll que permite el control de dispositivos
genéricos desde el punto de vista USB. Para interactuar con distintas tecnologías también se probó el
sistema con dispositivos controlados por radiofrecuencia. Se sobre escribió el firmware original del
router Azuzwl500w con OpenWrt una distribución de Linux para sistemas embebidos contando así
con una plataforma MIPS de bajos recursos y bajo costo. Se implanto JamVM, una maquia virtual de
JAVA especializada para este tipo de entornos y se experimentó con tecnologías de distribución como
jLSP y R-OSGI (Picerno, 2010).
3.11.2 Proyecto 2:
Sistema de comunicaciones basado en Ethernet para el control de sistemas empotrados
(Universidad Tecnológica de la Mixteca, México) Diciembre de 2009.
El proyecto establece una comunicación entre un sistema embebido y un centro de información.
El intercambio de información se realiza usando protocolos de suite TCP/IP. El encargado de
implementar el protocolo IP es el dispositivo MT100SEM de la firma Multitech System. El MUC
Atmega8 es el encargado de enviar las ordenes AT y controlar el intercambio de información con el
MT100SEM. El MUC es el encargado de configurar y controlar los dispositivos periféricos.
La interfaz del usuario es realizada en base a una interfaz web, las tareas realizadas en esta interfaz
son: identificar el usuario, interactuar con las salidas del sistema seleccionadas, mostrar entradas
digitales y análogas y mostrar información de cualquier sistema.
Todo realizado en la Universidad Tecnológica de Mixteca aprovechando su red de comunicación tipo
Ethernet, para un sistema de vigilancia (Universidad tecnologica de Mixteca, 2009).
46
3.11.3 Proyecto 3:
“Pago electrónico a través de teléfonos móviles”
En vista de la evolución de las comunicaciones surgió la idea de crear un sistema de pago a través del
teléfono móvil, el cual solicita la autorización para realizar el cobro a la tarjeta de crédito, mediante
un software instalado en el teléfono móvil.
El objetivo es ofrecer un mecanismo de pago electrónico a las empresas y personas desde cualquier
lugar geográfico con cobertura celular y así extender el uso de la infraestructura de pagos electrónicos
en los negocios de gran y menor tamaño (PYMES), tales como: comercio al menudeo, tiendas de
abarrotes, locales de comida, islas, papelerías, farmacias y hasta taxis (Espinosa Peñeherrera & Soto
Arango, 2009).
3.11.4 Proyecto 4:
Instalación de Linux para ARM en sistemas empotrados (Universidad de Granada, España,
2009).
Este proyecto cubre lo necesario para instalar Linux en una placa de desarrollo con procesador ARM
como la Beagle Board. Describe también un método para generar software ejecutable por la placa. Se
mostrara una forma sencilla de construir el sistema utilizando el emulador Qemu en la máquina de
escritorio de forma que se tenga el sistema básico funcionando rápidamente y sin complicaciones.
El método que se utilizó para instalar Linux y las demás herramientas en la Beagle Board se abstrae
gracias a la potencia de la placa y la disponibilidad de emuladores en los PCs actuales. Está basado
en el how to de Robert Nelson, el cual propone dos métodos independientes.
El primero consiste en cargar en una SD una imagen arrancable del instalador del sistema operativo.
Así una vez conectada la placa a un monitor, un teclado y un acceso a internet, se arranca la placa
con esa tarjeta y se instala Linux igual que se haría en un PC.
El segundo realiza la instalación en una máquina virtual en un PC. La instalación es similar a la que se
haría en un PC de forma nativa, pero en este caso se instalaría en la tarjeta SD. Una vez hecha la
instalación y configuración ya podemos arrancar la placa con la tarjeta introducida y acceder a ella
desde el PC a través del puerto serie.
Este proyecto muestra de manera minuciosa como instalar Linux en un sistema embebido lo cual es
muy interesante y provechoso. Por ser libre, muestra con respecto a nuestro proyecto la versatilidad
de estos sistemas para diferentes aplicaciones (Navarro R. C., 2010).
47
3.11.5 Proyecto 5:
Modulo didáctico de instrumentación electrónica implementado con tecnología FPAA
(Universidad Distrital Francisco José de Caldas, Facultad Tecnológica)
Es un proyecto de desarrollo ya que la finalidad del mismo es el aprovechamiento de nuevas
tecnologías en la instrumentación electrónica, entre ellas la FPGA, explorando sus ventajas con
respecto a lo que en la actualidad se usa en la Universidad Distrital. Debido a la poca aplicación que
hay en nuestro contexto educativo, este proyecto explora más a fondo esta tecnología, que puede ser
de gran utilidad en el diseño de sistemas de instrumentación electrónica en el grupo de investigación
“INTEGRA” y como consecuencia, permitir la reducción de materiales a utilizar, costos en el
proceso, y tiempo de ejecución de un diseño (Cuevas, 2007).
3.11.6 Proyecto 6:
“Propuesta de un plan para adquirir una solución tecnológica que permita la administración y
monitoreo de la red de cajeros automáticos del banco popular y de desarrollo comunal”
El Banco Popular y de Desarrollo Comunal, en su afán por sobresalir en el mercado financiero
costarricense y brindar más y mejores servicios a sus clientes, se encuentra en un proceso de
modernización de su plataforma tecnológica, incluyendo la red de cajeros automáticos.
Dado lo anterior, se estableció como objetivo principal en esta investigación, proponer un plan para
adquirir una solución tecnológica que permita la administración y monitoreo de la red de cajeros
automáticos del Banco Popular y de Desarrollo Comunal (Arias Guerrero, 2009).
4.
DISEÑO DE PROTOCOLO DE COMUNICACIÓN Y DESARROLLO DE LÓGICA
SOBRE SISTEMA EMBEBIDO
Inicialmente el proyecto se ha diseñado con transacciones básicas, las cuales corresponden a la
columna vertebral del software y obedecen a la lógica del negocio. Primordialmente se debe
mencionar que para este proyecto existen 2 tipos de protocolos empaquetados en la capa 4 del
modelo TCP/IP (Nivel de aplicación). El primer protocolo consiste en el diseño de mensajería
personalizada por parte del servidor de Pérez Abreu S.A, ubicado en República Dominicana y el
segundo corresponde al ISO 8583 para realizar descarga remota del aplicativo de una plataforma
externa llamada C.S.I (Costumer service information).
El tipo de programación que se ha utilizado en este caso ha sido Programación estructurada, la cual
está compuesta por un conjunto de técnicas que han ido evolucionando y aumentando
considerablemente la productividad del programa reduciendo el tiempo de depuración y
48
mantenimiento del mismo.
Esta programación estructurada utiliza un número limitado de estructuras de control, reduciendo así
considerablemente los errores (Alvarez, 2006).
Esta técnica incorpora:
Diseño descendente: El problema se descompone en etapas o estructuras jerárquicas.
Recursividad abstracta: Consiste en descomponer las acciones complejas en otras más simples
capaces de ser resueltas con mayor facilidad.
Estructuras básicas: Existen tres tipos de estructuras básicas:
o
Estructuras secuénciales: En donde cada acción sigue a otra acción secuencialmente. La salida de
una acción es la entrada de otra.
o
Estructuras selectivas: En estas estructuras se evalúan las condiciones y en función del resultado de
las mismas se realizan unas acciones u otras. Se utilizan expresiones lógicas.
o
Estructuras repetitivas: son secuencias de instrucciones que se repiten un número determinado de
veces.
Las principales ventajas de la programación estructurada son:
Los programas son más fáciles de entender
Se reduce la complejidad de las pruebas
Aumenta la productividad del programador
Los programas quedan mejor documentados internamente.
Debido a lo anteriormente señalado, se ha elegido este tipo de programación y ha facilitado
notablemente el desarrollo de cada uno de los módulos que componen el aplicativo, y además se ha
separado con eficiencia la capa de mensajería de interfaz gráfica, así como el modulo que maneja la
memoria del dispositivo
4.1 TCP – IP
La comunicación mediante el protocolo TCP/IP se realiza a través de la red Ethernet de intranet o
internet que posea la infraestructura del sitio donde se ubique el datafono.
Es el método de comunicación más rápido y efectivo que se utiliza en los datafonos, esto debido a que
el medio de trasmisión no es compartido y puede ser utilizado todo el ancho de banda del mismo para
el establecimiento de la comunicación y la transferencia de información.
49
Ventajas
El protocolo a implementar se define entre el cliente y el servidor, con esto se aprovecha al
máximo el ancho de banda.
La implementación de protocolo SSL brinda un nivel de encripción de datos óptimo.
La reanudación de descargas interrumpidas es definida entre cliente y servidor.
Desventajas
La definición de protocolo y funcionalidad completa implica un desarrollo estructural
avanzado que contemple todos los escenarios presentes en un sistema de comunicación.
La idea es utilizar este protocolo ya que posee un nivel de seguridad confiable con adiciones de
protocolos criptográficos sobre el mismo, además de ser un protocolo orientado a conexión, lo cual
indica que se implementara con conexión por demanda y sacara el máximo provecho del sistema
GPRS.
En la ilustración 12 se observa un esquema simple de la comunicación que se lleva a cabo en este
punto.
ILUSTRACIÓN 12: ESQUEMA TCP
4.2 GPRS
Es necesario seguir una serie de pasos en el datafono para configurar la conexión GPRS, una vez se
configura el modem GPRS del datafono con los parámetros correspondientes al proveedor de
servicios, se establece la comunicación entre el datafono y el operador de telefonía. Esta
comunicación se realiza mediante protocolo PPP; Sin embargo, la comunicación entre el operador de
telefonía y el servidor externo se realizara mediante protocolo TCP/IP.
50
Para transmitir datos mediante GPRS se deben tener en cuenta los parámetros de comunicación del
servidor externo, estos parámetros son:
a. Dirección Lógica (IP).
b. Puerto TCP de escucha.
La conexión del datafono hasta el servidor externo presenta los siguientes pasos que deben
desarrollarse al momento de enviar datos a través de la red:
1.
2.
3.
4.
5.
6.
Establecimiento de la conexión PPP.
Autenticación con el proveedor de telefonía y datos de navegación móvil.
Apertura del socket de comunicación TCP.
Envío de datos en PPP.
Liberación de recursos lógicos y físicos del proceso de comunicación TCP.
Liberación de los recursos utilizados por la conexión PPP.
Los parámetros de configuración del datafono son los siguientes:
FRECUENCIA MODEM
Modem 850/1900
Desea cambiar de bandas?
SI = ENTER
NO = CLR
Cambio de banda dependiendo del operador
ILUSTRACIÓN 13: CONFIGURACÍON BANDAS
El APN (Access Point Name) se configure de manera manual o se elige alguno por defecto
dependiendo el operador. Igualmente se establece usuario y contraseña si posee.
ILUSTRACIÓN 14: CONFIGURACIÓN APN.
51
APN
IKKLKL
Nuevo Valor:
Especificación APN manualmente
ILUSTRACIÓN 15: INGRESAR APN
User:
IKKLKL
Nuevo Valor:
Usuario APN
ILUSTRACIÓN 16: INGRESAR USUARIO SIN APN
Contraseña APN
ILUSTRACIÓN 17: INGRESAR CONTRASEÑA
La Ilustración 18 describe el proceso de negociación y autenticación del Terminal punto de venta
frente a la red de telefonía móvil para el acceso a la transferencia PPP.
52
ILUSTRACIÓN 18: DIAGRAMA DE FLUJO CONEXIÓN GPRS
4.3 Diagrama de flujo del desarrollo completo (Con protocolo de comunicación implícito)
Ilustración 19 siguiente página.
53
54
ILUSTRACIÓN 19: DIAGRAMA DE FLUJO PRINCIPAL
4.4 Diagrama de clases básicas del desarrollo
ILUSTRACIÓN 20: DIAGRAMA DE CLASES
4.5 Diagrama de casos de uso
En el siguiente diagrama se encuentra la descripción escrita del comportamiento del sistema al
afrontar cada una de las tareas que demanda este tipo de negocio. Esta descripción nos muestra 5
actores, el autorizador, el operario de la máquina (Sistema embebido), la banca de apuestas, que es la
central que registra por puntos del territorio las máquinas, el cliente, el cual consume el producto que
se comercializa con la máquina y el C.S.I o servicio de información del cliente, del cual depende la
descarga remota de nuevas versiones del aplicativo generado.
55
ILUSTRACIÓN 21: CASOS DE USO
56
4.6 Transacciones implementadas
A continuación se presentan las transacciones dispuestas y anteriormente mencionadas, las cuales se
encuentran embebidas en las tecnologías y protocolos anteriormente descritos (TCP/IP y GRPS).
Para las siguientes transacciones se tendrán en cuenta las siguientes identificaciones de brindaran
mayor claridad al momento de explicar la construcción de una transacción:
ID Transacción > AZUL ( 2 Bytes en formato ASCII )
Serial Terminal > VERDE ( 8 Bytes en formato ASCII )
Separador> ROJO ( 1 Byte en formato ASCII ),
4.6.1 Login-Inicialización
En ningún proceso se permite el borrado del archivo de memoria por parte del datafono, solo se
recurre a realizar un reciclado de memoria por fechas, lo cual será más ampliamente explicado en
transacciones posteriores.
En primera instancia se contempla una inicialización con la máquina totalmente vacía,
posteriormente se contemplara una actualización de productos con una máquina previamente
inicializada.
Login online
Usuario:
IKKLKL
Clave:
ILUSTRACIÓN 22: LOGIN
TX:
09
|
2a000206
|
0-1
Estado de inicialización: 0 no está inicializado, 1 ya ha inicializado el pos
57
|
1243
Usuario (4 bytes en ASCII)
|
1234
Clave (4 bytes en ASCII)
|
1234
Checksum (4 bytes en ASCII)
El usuario y la clave componen el Login del aplicativo, lo que quiere decir que son las credenciales de
ingreso que mantendrá la máquina como respuesta del servidor para realizar transacciones de ahora
en adelante.
Ejemplo:
09|2A000665|1234|1234|1234.
Existen 2 posibles respuestas validas a este tipo de petición o envío.
Respuesta a una solicitud errada:
RX:
09
|
1-2 transacción errónea (1 byte)
|
Separador
02 cantidad errores (2 bytes)
@
01 línea de error (2 bytes)-cuando es genérico va en ceros-(inicia en uno)
|
Cadena de texto que describe el error.
Ejemplo:
09|1|01@00|error en checksum
09|2|02@01|msj1@03|msj2
Respuesta a una solicitud exitosa:
58
RX:
09
|
0
El cero indica que la respuesta fue exitosa, que no hay errores en el envío.
|
201112271300
Fecha y hora para sincronización del POS (14 bytes)
|
S
Este parámetro indica si el aplicativo funcionará offline, S=Si.
@
<o>
Carácter que indica inicialización (1 byte).
80
Bitmap de tablas (1 byte), indica las tablas que se van a cargar al POS.
01
id tabla (1byte-BDC)
00xx
longitud del dato del registro (2 bytes-BCD)
01
registro (1bytes-BCD)-inicia siempre en uno
Data
longitud variable.
Se puede presentar el caso de no inicializar, para este caso se compara el carácter que sigue a la @
Si es:
< Este carácter indica que no viene inicialización.
> Con este carácter se indica que a continuación viene inicialización completa.
Seguido a ese carácter se envía un bitmap de tablas el cual indica cual tabla debe ser formateada en el
POS, este bitmap es un único byte por tanto se limita la cantidad de tablas a 8.
El bitmap de tablas se construye de la siguiente manera: El bit más significativo representa el id de
tabla 01 el bit siguiente es el id 02 y así sucesivamente para los distintos id de cada tabla.
Tabla ventas ID 01
Campo
Longitud
Formato
Id lotería
1
BCD
Nombre lotería
20
ASCII
abreviatura
4
ASCII
59
Fecha-hora sorteo
14
ASCII
Tipo venta
2
ASCII
Juegos disponibles
30(variable)
BCD
TABLA 4: CABECERA DE VENTAS
Nota: Esta tabla relaciona tanto loterías como operadores de recarga cuando sea un servicio de
recarga solo puede venir un juego habilitado.
Ejemplo con la inicialización de una lotería:
01 >Id tabla
00 45 >Longitud del registro
01 >Numero de Registro de la tabla
01 > Id Lotería
4e 41 43 2e 20 54 41 52 44 45 20 20 20 20 20 20 20 20 20 20 > Nombre Lotería
4c 4f 4e 54 > Abreviatura Lotería
32 30 31 35 30 37 32 31 31 33 35 34 30 30 > Fecha Sorteo
30 31 > Tipo de venta (01 Lotería, 02 Recargas)
01 02 03 15 > Juegos habilitados por ID
Después de inicializar cada una de las loterías, se inicializan los juegos, los cuales se identifican con
un ID que identifica cada uno de estos:
Tabla juegos ID 02
Campo
Longitud
Formato
Id juego
1
BCD
Nombre juego
5(máximo para
impresión-pantalla)
ASCII
Longitud de apuesta
1
BCD
Prioridad juegos
1
BCD
Buscar Lotería
1
BCD
Monto Mínimo
3
ASCII
Monto Máximo
7
ASCII
Limite Numero
7
ASCII
TABLA 5: TABLA DE JUEGOS
60
Ejemplo con la inicialización de los juegos:
02 > Id tabla
00 27 > Longitud del registro
01 > Número de registro de la tabla
01 > Id Juego
51 55 49 4e 4e > Nombre Juego
02 > Longitud Apuesta o cantidad de números necesarios para activar el juego
01 > Prioridad del juego, el juego puede ser de prioridad 2 y jugarse con 2 loterías a la vez.
01 > Buscar Lotería, el cual se utiliza para poder elegir el tipo de lotería cuando la prioridad es 2.
30 30 31 > Monto mínimo para el juego.
30 30 30 30 35 30 30 > Monto máximo para el juego.
30 30 31 30 30 30 30 > Limite número, o cantidad de veces que se puede jugar el juego diario.
Nota:
1. Se adicionan campos de longitud para asignar dinámicamente el juego con su respectiva
longitud.
Se asigna id de prioridad para los juegos con el mismo número de longitud, nunca se va a repetir la
prioridad más alta– este oscila entre 1 - 2. Se debe ajustar la grilla para visualizar 5 caracteres al
igual que se debe ajustar el ticket.
Tabla ticket ID 03
Campo
Longitud
tipo
Texto
48(variable)
ASCII
TABLA 6: TABLA DE PIE DE TIQUETES
Nota:
Para esta tabla los registros son así:
01 siempre titulo
02 siempre dirección
De 03 en adelante es el pie de página del ticket
61
Ejemplo con la inicialización del texto de los tiquetes:
03 > Id Tabla
00 20 > Longitud de los datos de la tabla
01 > Numero de registro de la tabla
42 61 6e 63 61 73 20 49 6e 66 61 6e 74 65 20 41 62 72 65 75 > Texto Titulo
03 > Id Tabla
00 09 > Longitud de los datos de la tabla
02 > Numero de registro de la tabla
53 41 4e 54 49 41 47 4f 2e > Texto de la dirección de la banca de apuestas
03 > Id Tabla
00 18 > Longitud de los datos de la tabla
03 > Registro de pie de página del tiquete
54 65 6c 20 3a 20 38 30 39 2d 30 30 30 2d 30 30 30 31 >Texto de pie de página
Tabla productos ID 04
Campo
Longitud
Formato
Nombre
19
ASCII
Id venta
2
ASCII
TABLA 7: TABLA DE PRODUCTOS
Nota:
Se asegura que el id 01 corresponde a loterías y el id 02 a recargas, a medida que se adicionen
productos se agregaran los id fijos de 03 en adelante.
Ejemplo con la inicialización de los tipos de producto:
04 > Id Tabla
00 21 > Longitud datos
01 > Número del registro de la tabla
4c 4f 54 45 52 49 41 20 20 20 20 20 20 20 20 20 20 20 20 > Nombre producto
30 31 > Id del tipo de producto
04 > Id Tabla
00 21 > Longitud de datos de la tabla
02 > Número del registro de la tabla.
52 45 43 41 52 47 41 53 20 20 20 20 20 20 20 20 20 20 20 30 32 > Nombre producto
62
04 > Id tabla
00 21 > Longitud datos
03 > Número del registro de la tabla
56 45 4e 54 41 53 20 20 20 20 20 20 20 20 20 20 20 20 20 30 33 > Nombre Producto
Cada uno de los tipos de tablas y los registros hacen que el desarrollo del aplicativo a nivel de código
sea mucho más sencillo y eficiente debido a que se utiliza la porción de memoria necesaria porque se
envían las longitudes de los registros. Si en momento determinado se necesitan implementar más
tablas, debido a esta dinámica se hará muy sencillo por que a nivel de código diseñó con la lógica más
básica en la cual se señala cada tabla por casos o 'case'.
ILUSTRACIÓN 23: MENU PRINCIPAL
Las siguientes transacciones han sido construidas con una mensajería completamente en
formato ASCII, ya que para el servidor es mucho más sencillo interpretar mensajería en dicho
formato, aunque este tipo de mensajería consuma un mayor número de datos, la interpretación
por parte del servidor está garantizada al ser formato ASCII.
4.6.2 Transacción de venta
Antes de explicar este módulo, se debe mencionar que este desarrollo cuenta con un sistema de venta
offline, el cual entra en funcionamiento cuando la conexión a la red es problemática.
Este tipo de problemas son muy frecuentes en República Dominicana debido a la fragilidad en la
infraestructura de comunicaciones móviles en dicho país.
Este sistema es capaz de vender fuera línea y generar un lote completo de ventas para sincronizar con
el servidor. Aunque este tipo de procedimiento no es muy confiable, se ha diseñado una lógica que no
permite de ninguna manera perder las ventas que se han hecho offline desde el POS.
63
A pedido del cliente se ha solicitado que máximo se guarden 4 días de transacciones sin sincronizar,
ya que de allí en adelante es un tiempo exagerado debido a la lógica que manejan los juegos de azar en
sus sorteos.
Como consecuencia a este módulo de venta offline existe un módulo de sincronización que envía
estas apuestas al servidor el cual será explicado más adelante.
ILUSTRACIÓN 24: MODO OFFLINE
Es necesario tener en cuenta que la estructura de la venta es la misma para offline y online. Solo va a
cambiar el Id de transacción, de igual manera sucederá con la venta de recargas.
Se debe imprimir la lotería en el tiquete de venta tener y se debe tener en cuenta el tema del súper pale
puesto que es un número de 4 dígitos que juega con 2 loterías a la vez (interfaz especial para
seleccionar la lotería con la cual se conjuga el número del súper pale).
Esta trama contiene la siguiente cabecera:
Campo
Longitud
Id transacción
2 Bytes
STAN(Consecutivo transacción)
6 Bytes
Cantidad de apuestas
3 Bytes
Serial Terminal
8 Bytes
Serial Sim Card
20 Bytes (Se rellena con ceros a la izquierda)
Valor en dinero del tiquete
9 Bytes ( Viajan 2 ceros a la derecha como decimales)
Fecha y hora de venta
14 Bytes ( Importante si se hace OFFLINE)
Código generado por el POS
7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Código de cliente frecuente
5 Bytes
Separador de fin de cabecera
1 Byte @
TABLA 8: CABECERA DE LA VENTA
64
Ejemplo cabecera TX:
00|000003|003|3C039714|00008954871223654878|000013300|20150723171258|0000000|00000@
Después del separador de '@' se envía el detalle de cada venta:
Campo
Longitud
Id del juego
2 Bytes
Id de lotería que contiene el juego
2 Bytes
Total de la apuesta
7 Bytes( Viaja con 2 bytes a la derecha para decimales)
Numero apostado
Variable y depende del tipo de juego
TABLA 9: DETALLE DE LA VENTA
En caso de existir más de un juego en el detalle, estos se separan por @, el último juego no termina
con @.
Ejemplo del detalle de la venta:
04|03|0005600|14@05|03|0004500|4587@06|03|0003200|212122
Captura de venta completa con cabecera TX:
00|000003|003|3C039714|21568954871223654878|000013300|20150723171258|0000000|00000@
04|03|0005600|14@05|03|0004500|4587@06|03|0003200|212122
ILUSTRACIÓN 25: GRILLA
65
Existen 2 tipos de recepción, exitosa y declinada. En el caso de recepción declinada:
00 id transacción (2 bytes en ASCII)
01 id transacción (2 bytes en ASCII)
|
Separador
1
Código de respuesta con error
|
Separador
02 cantidad errores (2 bytes)
@ Separador
01 línea de error (2 bytes)-cuando es genérico va en ceros-(inicia en uno)
|
Separador
Texto que describe el tipo de error.
Para la mayor parte de las transacciones se utiliza este tipo de respuesta cuando existe algún
error, por ello estará referenciado en este apartado.
Ejemplo:
09|1|02@01|msj1@03|msj2
Estructura de la respuesta del servidor:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
STAN(Consecutivo de la transacción)
6 Bytes
Código de Autorización
10 Bytes ( Impreso en Código de barras)
Número de tiquete generado por el servidor
7 Bytes
Fecha y hora de la venta
14 Bytes
Fecha y hora del sorteo
8 Bytes
TABLA 10: RESPUESTA DE VENTA
Captura de recepción exitosa RX:
00|0|000001|1234567890|1234567|20111228120000|20111228
66
ILUSTRACIÓN 26: VENTA APUESTA
ILUSTRACIÓN 27: TIQUETE DE VENTA
4.6.3 Transacción de reversión
La reversión se ejecuta siempre y cuando el aplicativo sea 100% ONLINE, en ningún caso existirán
las reversiones fuera de línea. Un reverso se presenta a nivel financiero cuando no se recibe
respuesta alguna en la solicitud de una venta, lo que indica que es probable que el servidor no haya
67
recibido el envío de lo transacción o que existió algún problema de red tanto en el envío como en la
respuesta.
Se envía id de transacción 02 y la trama se envía igual que una venta con cabecera incluida:
Captura de reverso completo con cabecera TX:
02|000003|003|3C039714|21568954871223654878|000013300|20150723171258|0000000|00000@
04|03|0005600|14@05|03|0004500|4587@06|03|0003200|212122
La respuesta de error es exactamente igual a la venta en su formato.
Respuesta con un envío exitoso RX:
02 Id transacción (2 bytes en ASCII)
|
Separador
0
Código de respuesta (1 Byte)
ILUSTRACIÓN 28: REVERSO EXITOSO
4.6.4 Transacción de anulación
La transacción de anulación cuenta con una particularidad de Timeout, la cual el servidor toma de
manera arbitraria. Lo que quiere decir que pasados cierta cantidad de minutos la transacción no se
puede anular.
El Id de la transacción es un 03, este tipo de transacción solo está disponible desde el POS que
imprimió la venta, de lo contrario es rechazada por el servidor.
La anulación se hace digitando el número de verificación del ticket, se compara en el pos y luego se
solicita la información del código de referencia para evitar fraudes.
68
ILUSTRACIÓN 29: CAMPO DE ANULACIÓN
El siguiente es el esquema de envío en la anulación TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Terminal
8 Bytes
Usuario
4 Bytes
Referencia del tiquete a anular
7 Bytes
STAN( Consecutivo de venta )
6 Bytes
Tipo de anulación (1 OFFLINE, 0 ONLINE)
1 Byte
Total de offline ( Por si el tiquete fue sincronizado)
12 Bytes
Fecha y hora de anulación
14 Bytes
TABLA 11: ENVÍO DE ANULACIÓN
Captura de anulación TX:
03|3C039714|4321|1300530|000004|0|000000000000|20150724125809
Tipo anulación:
0 ONLINE
1 OFFLINE
Respuesta Exitosa de una anulación RX:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Total del tiquete anulado
9 Bytes
Fecha y hora de anulación
14 Bytes
TABLA 12: RESPUESTA DE ANULACIÓN
69
Ejemplo RX:
03|0 | 001000000 |20111228120000
4.6.5 Transacción de Batch Upload
En términos financieros un Batch se produce en el momento en que el autorizador de transacciones
en una de sus consultas registra un total de dinero en las transacciones diferente al POS. En ese
momento el POS debe enviar todo el lote de transacciones que tenga en su memoria al autorizador
para que contrasten los totales y no se pierda dinero.
Este tema se ejecuta también si en el cierre de sesión, la cantidad de ventas difiere como
consecuencia de las ventas offline, en este caso se sugiere al POS realizar sincronización manual
la cual será explicada posteriormente a nivel transaccional.
Transacción de envío TX:
Se envía id de transacción 05 y tiene el mismo formato de una transacción de venta.
La respuesta de error es exactamente igual a la venta en su formato.
Respuesta exitosa RX:
05 Id transacción (2 bytes en ASCII)
|
0
Código de Respuesta (1 byte)
4.6.6 Transacción de lista de números
Es una transacción bastante específica y muy importante, ya que nos detalla los registros de cada
lotería, incluyendo dinero y números de cada transacción. Particularmente esta transacción además
de retornar los registros específicos de cada lotería, permite también la impresión de los números
que se han jugado con dichas loterías en la parte posterior de estos datos, estos datos son impresos y
tomados desde la máquina. Después de la respuesta de la transacción se comparan los resultados
respondidos por el servidor y los computados por la máquina, de existir alguna diferencia se debe
enviar un Batch.
70
ILUSTRACIÓN 30: MENU CONSULTAS
Formato de envió de la transacción:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha inicial del reporte
14 Bytes
Fecha final del reporte
14 Bytes
TABLA 13: ENVÍO DE BATCH
Captura de envió de la transacción TX:
14|3C039714|4321 |20150724000000|20150724235959
Formato de respuesta Cabecera:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de loterías que registran ventas
3 Bytes
Total de ventas
12 Bytes
Total de pagos hechos
12 Bytes
Porcentajes a los vendedores
12 Bytes
Total de recibido por el POS
12 Bytes
TABLA 14: CABECERA LISTA NÚMEROS
71
Captura de respuesta exitosa de la transacción RX cabecera:
14|0 |001|00000005600|00000000000|000000000000|000000005600
Posterior a la cabecera se envía el detalle de la transacción, es decir la información por lotería
separado por un @ el cual separa el detalle de la transacción, y varía dependiendo de la cantidad de
loterías que se presenten en el reporte, cada lotería va separada con un @.
Formato del detalle de la transacción:
Campo
Longitud
Id Lotería
2 Bytes
Números ganadores
15 Bytes
Total de ventas
12 Bytes
Total Pagos
12 Bytes
Porcentajes a los vendedores
12 Bytes
Total de recibido por este tipo de lotería
12 Bytes
TABLA 15: DETALLE DE RESPUESTA LISTA NÚMEROS
Captura de respuesta exitosa RX:
01 | ****** |000000005600|000000000000|000000000000|000000005600
ILUSTRACIÓN 31: PARAMETROS DE CONSULTAS
72
ILUSTRACIÓN 32: TIQUETE DE LISTA DE NÚMEROS
La respuesta errónea tiene el mismo formato de las transacciones anteriores, solo cambia el id de la
transacción.
4.6.7 Transacción de consulta de ventas
Lo más importante en este tipo de transacción antes de realizar la recepción es tener en cuenta el
rango de fechas en el cual se va a realizar la consulta. Esta transacción especialmente debe tener
fecha inicial de consulta y fecha final de consulta. Se debe enviar un total de ventas online y offline
por separado.
73
En la consulta debe enviar el total offline con el fin de saber si es necesario sincronizar, así mismo
se va a verificar que los totales online entre el servidor y el POS coincidan. En la respuesta del
servidor el campo de diferencia es la cantidad de dinero que le falta al POS por sincronizar,
generalmente antes de que viaje esta transacción, se realiza una consulta de lista números, lo cual es
solicitado por el servidor para obtener un resultado más exacto del reporte.
Este reporte es muy general y se debe imprimir en pantalla y en papel.
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha inicial del reporte
14 Bytes
Fecha final del reporte
14 Bytes
Total de venta ONLINE
9 Bytes
Total de venta OFFLINE
9 Bytes
TABLA 16: ENVÍO DE CONSULTA
Captura del envío TX:
06|2a000208|1234|20111228180000|20111228180000|001000000|000500000
Si el online no coincide se hace Batch en el rango de fechas especificado.
El error se va a validar por el siguiente número que llega al id de transacción: Si en el código de
respuesta llega en , el aplicativo procede a realizar un Batch, ya que habría diferencia entre los
montos de POS y el servidor, de tratarse del número 2, se seguiría la lógica de las transacciones
anteriores.
Formato de respuesta exitosa RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Total en ventas
12 bytes (con 2 decimales a la derecha)
Total de juegos
2 Bytes
74
Separador de juegos
1 Byte @ Indica de los datos de un juego
Id de juego
2 Bytes
Id de lotería
9 Bytes
Total de venta del juego
12 Bytes ( Con 2 decimales a la derecha)
Separador
1 Byte @ Indica finalización de los datos de un juego
Total entre OFFLINE y Sincronizado
12 Bytes
TABLA 17: RESPUESTA DE CONSULTA
Captura de respuesta completa RX:
06|0 |000000005600|01@ 02|01|000000005600@000000000000
ILUSTRACIÓN 33: PARAMETROS DE REPORTE
ILUSTRACIÓN 34: TIQUETE CONSULTA GENERAL
75
4.6.8 Transacción de pagos
En este módulo se solicita al operador del POS el STAN del ticket y el serial de la máquina donde
se vendió el ticket:
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Referencia del tiquete
7 Bytes
STAN (Consecutivo tiquete)
6 Bytes
Serial Máquina que hizo la venta
8 Bytes
TABLA 18: ENVÍO DE PAGOS
Envío del POS TX:
07|2a000203|1234|1234567|123456|2a000123
Recepción exitosa RX:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Hora y fecha del pago
14 Bytes
Número de verificación
10 Bytes
Total de premio
9 Bytes
TABLA 19: RESPUESTA DE PAGOS
Captura de respuesta RX:
07|0 |20111229130000|1234567890|009000000
Cuando se concrete el pago se debe realizar una impresión de un tiquete certificando el pago.
La respuesta de error es igual a la respuesta de la venta.
76
4.6.9 Transacción de consulta de tiquetes
Este módulo se ejecuta antes de realizar el pago del tiquete, se pueden hacer consultas desde
cualquier terminal, si el tiquete era ganador se ingresa al módulo de pago de tiquete.
ILUSTRACIÓN 35: CONSULTA DE TIQUETES
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Número de tiquete
7 Bytes
Referencia del tiquete
10 Bytes
TABLA 20: ENVÍO CONSULTA TIQUETES
Captura de Envío POS TX:
08|2a001234 |1234|1234567|2333336666
Captura de respuesta exitosa (RX):
08
Id transacción
|
0
Código de respuesta exitoso
|
123456700
Premio (9 bytes) dos decimales, nunca puede ser cero el total del premio.
La recepción en error es similar a las demás transacciones, solo cambia el Id.
77
4.6.10 Transacción de cierre de ventas
En la transacción de cierre lo más importante es enviar las fechas de inicio del login y del momento
en que se envía la misma transacción, es decir la fecha final. Nuevamente al igual que en las
consultas se envía el total online y el total offline de todas las ventas realizadas para realizar una
posterior sincronización en caso de ser necesario. El momento del cierre marca los lotes de ventas
en el servidor y los clasifica por fechas y usuarios.
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha en la cual se hizo inicialización
14 Bytes
Fecha actual
14 Bytes
Total de ventas ONLINE
9 Bytes
Total de ventas OFFLINE
9 Bytes
TABLA 21: ENVÍO DE CIERRE
Captura de envío de la transacción TX:
10|2a012345 |1234|20111229080000|20111230040500|002000000|000100000
Formato de respuesta exitosa RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Total en ventas
12 bytes (con 2 decimales a la derecha)
Total de juegos
2 Bytes
Separador de juegos
1 Byte @ Indica de los datos de un juego
Id de juego
2 Bytes
Id de lotería
9 Bytes
Total de venta del juego
12 Bytes ( Con 2 decimales a la derecha)
Separador
1 Byte @ Indica que viene el total entre OFFLINE Y
Sincronizado
Total entre OFFLINE y Sincronizado
12 Bytes
TABLA 22: RESPUESTA DEL CIERRE
78
Captura de respuesta Exitosa RX:
10|0|000000007900|02@02|01|000000005600@04|03|000000002300@000100000000
En este tipo de transacción el error puede apuntar a un Batch si los totales no coinciden
En otro caso el formato de respuesta con solicitud errónea será la misma de las anteriores
transacciones.
ILUSTRACIÓN 36: PANTALLA DE CIERRE
4.6.11 Transacción de Reporte Parcial
El reporte parcial nos indica la cantidad de ventas que se ha hecho hasta el momento, este tipo de
reporte es permitido realizar por loterías para ser mucho más preciso.
ELIJA LOTERIA
1.
2.
3.
4.
5.
NAC. TARDE
NAC. NOCHE
LEID.
NOCHE
IKKLKL
REAL TARDE
LTKA TARDE
ILUSTRACIÓN 37: SELECCIONAR LOTERIA EN REPORTE PARCIAL
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha en la cual se hizo inicialización
14 Bytes
79
Fecha final del reporte
14 Bytes
Id de lotería a consultar
2 Bytes
TABLA 23: REPORTE PARCIAL ENVÍO
Captura del envío TX:
11|3C039714|4321|20150724000000|20150724235959|01
Formato de respuesta exitosa RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Total en ventas
12 Bytes (con 2 decimales a la derecha)
Total en pagos
12 Bytes (con 2 decimales a la derecha)
Tiquetes pagos en la lotería
4 Bytes
Diferencia entre ventas y pagos
12 Bytes
Titulo de la lotería consultada
31 Bytes, se justifica con espacios a la derecha
Nombre de la banca que distribuye la lotería
9 bytes, se justifica con espacios a la derecha
TABLA 24: RESPUESTA REPORTE PARCIAL
Captura de Respuesta RX:
11|0|000000000000|000000000000|0000|000000000000|Nac. Tarde
|Banca #00
El error en respuesta maneja el mismo formato de las anteriores transacciones.
ILUSTRACIÓN 38: TIQUETE DE REPORTE PARCIAL
80
4.6.12 Transacción de consulta de tiquetes ganadores
La consulta de tiquetes ganadores responde en una sola transacción la cantidad de tiquetes
ganadores por lotería y los pagos que se han realizado de los mismos, al igual que todas las
consultas del proyecto, es necesario imprimir un tiquete con todos estos datos.
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha inicial de la consulta
14 Bytes
Fecha final del reporte
14 Bytes
TABLA 25: CONSULTA DE TIQUETES GANADORES
Captura de solicitud TX:
15 |3C039714|4321|20150724000000|20150724235959
La respuesta se divide en cabecera y detalles de la transacción:
Formato de respuesta cabecera RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de loterías en la respuesta
3 Bytes
Total en ventas
12 Bytes (con 2 decimales a la derecha)
Total en pagos
12 Bytes (con 2 decimales a la derecha)
Porcentajes a los vendedores
12 Bytes (con 2 decimales a la derecha)
Total recibido después de descuentos
12 Bytes (con 2 decimales a la derecha)
Cantidad de tiquetes ganadores
3 Bytes
TABLA 26: RESPUESTA TIQUETES GANADORES
Formato de respuesta detalle RX:
Después de la cantidad de tiquetes ganadores se separa con un @ las loterías que vienen en la
respuesta de la transacción, la cantidad de @ indica la cantidad de loterías, y posterior a ello viene
este formato de envío, el cual se repite según la cantidad de loterías:
81
Campo
Longitud
Id Lotería
2 Bytes
Pagos en números ganadores
15 Bytes
Total en ventas
12 Bytes (con 2 decimales a la derecha)
Total en pagos
12 Bytes (con 2 decimales a la derecha)
Porcentajes a los vendedores
12 Bytes (con 2 decimales a la derecha)
Cantidad de números ganadores
3 Bytes
TABLA 27: DETALLE DE RESPUESTA TIQUETES GANADORES
Si en la cantidad de números ganadores existe un valor mayor a cero se debe imprimir en el tiquete
la data con los números ganadores y el detalle que conlleva cada número ganador, la cantidad de
bytes máxima por lotería para números ganadores y detalles de cada número esta en 32 bytes, de
pasar este límite se corta la data proveniente del servidor y se muestra solo lo que el POS logró
almacenar sin proceder a un desborde.
Captura de respuesta RX:
15 |0|001|000000005600|000000000000|000000000000|000000005600|000 @ 01|******
|
000000005600|000000000000|000000000000|000000005600|000
ILUSTRACIÓN 39: REPORTE DE TIQUETES GANADORES
82
4.6.13 Transacción de consulta de cierre por fecha
Este tipo de consulta se realiza a manera general y retorna todos los valores correspondientes a cada
una de las loterías relacionadas con las fechas que se envían en la previa solicitud.
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha inicial de la consulta
14 Bytes
Fecha final del reporte
14 Bytes
TABLA 28: ENVÍO DE CIERRE POR FECHA
Captura del envío TX:
13 |3C039714 |4321 |20150724000000 |20150724235959
Formato de respuesta RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de fechas consultadas
3 Bytes, indica la cantidad de separadores @
Nombre de la banca
31 Bytes
Fecha del reporte
14 Bytes
Total de las ventas
12 Bytes ( Con 2 decimales a la derecha)
Total de los pagos
12 Bytes ( Con 2 decimales a la derecha)
Total de comisiones de venta
12 Bytes ( Con 2 decimales a la derecha)
Beneficio pérdida
12 Bytes ( Con 2 decimales a la derecha)
Total Recibido
12 Bytes ( Con 2 decimales a la derecha)
Separador (Separa los reportes por fechas)
1 Byte @
Fecha del reporte especifica
8 Bytes
Total venta una fecha
12 Bytes ( Con 2 decimales a la derecha)
Total pagos una fecha
12 Bytes ( Con 2 decimales a la derecha)
TABLA 29: RESPUESTA DE CIERRE POR FECHA
83
Captura de respuesta de una transacción completa RX:
13|0|001|3C039714|20150724172512|000000005600|000000000000|000000000000|000000005600|
000000005600@20150724 |000000005600|000000000000
El error en respuesta maneja el mismo formato de las anteriores transacciones.
ILUSTRACIÓN 40: REPORTE DE CIERRE POR FECHA
4.6.14 Transacción de sincronización
Este tipo de transacción es clave en todo el desarrollo, ya que permite la interactividad entre el
modulo offline y el servidor, por medio de esta transacción se sincronizan todas las apuestas que se
hacen offline, lo que permite legalizar todas las transacciones en el servidor.
La cabecera y datos de la transacción son los mismo de la transacción de ventas, lo único que
cambia es el id de la transacción, la cual se marca con un 01 cuando es offline, lo cual indica que los
datos son de una sincronización. Todos los datos viajan en formato ASCII al igual que en la mayoría
de las transacciones.
84
Formato de envío cabecera TX:
Campo
Longitud
Id transacción
2 Bytes
STAN(Consecutivo transacción)
6 Bytes
Cantidad de apuestas
3 Bytes
Serial Terminal
8 Bytes
Serial Sim Card
20 Bytes (Se rellena con ceros a la izquierda)
Valor en dinero del tiquete
9 Bytes ( Viajan 2 ceros a la derecha como decimales)
Fecha y hora de venta
14 Bytes ( Importante si se hace OFFLINE)
Código generado por el POS
7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Código de cliente frecuente
5 Bytes
Separador de fin de cabecera
1 Byte @
TABLA 30: ENVÍO DE SINCRONIZACIÓN
Formato de envío detalle de la transacción TX:
Después del separador de '@' se envía el detalle de cada venta:
Campo
Longitud
Id del juego
2 Bytes
Id de lotería que contiene el juego
2 Bytes
Total de la apuesta
7 Bytes( Viaja con 2 bytes a la derecha para decimales)
Numero apostado
Variable y depende del tipo de juego
TABLA 31: DETALLE DEL ENVÍO EN SINCRONIZACIÓN
En caso de existir más de un juego en el detalle, estos se separan por @, el último juego no termina
con @.
Captura de Envío TX:
01|000009|001|3C039714|88994994900303042049|000002300|20150724163040|0975202|00000
@04 |03|0002300|12
85
Formato de respuesta exitosa RX:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
STAN(Consecutivo de la transacción)
6 Bytes
Código de Autorización
10 Bytes ( Impreso en Código de barras)
Número de tiquete generado por el servidor
7 Bytes
Fecha y hora de la venta
14 Bytes
Fecha y hora del sorteo
8 Bytes
TABLA 32: RESPUESTA DE SINCRONIZACIÓN
Captura de respuesta exitosa RX:
01|0|000004|9507704045|0349679|20150729182944|20150729
El error en respuesta maneja el mismo formato de las anteriores transacciones.
ILUSTRACIÓN 41: PANTALLA DE SINCRONIZACIÓN
Es importante saber que en este tipo de transacción la única que recibe respuesta es la primera
solicitud, lo que indica que al existir más de 1 transacción offline por sincronizar, solo se hace el
envío y el servidor no responderá, debido al tiempo que se toma una sola transacción en sincronizar,
la cual en óptimas condiciones toma alrededor de 6 segundos. Al multiplicar este valor por al menos
10 transacciones nos toma 1 minuto, tiempo el cual es bastante elevado teniendo en cuenta el nivel
de ventas registrado en República Dominicana.
Con respecto a lo anterior se ha desarrollado una sola transacción que recibe el nombre de consulta
de sincronización y su formato es el siguiente:
86
Formato de envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Fecha de las ventas a consultar
8 Bytes
Cantidad de transacciones a consultar
4 Bytes
Número de tiquete a consultar
7 Bytes
TABLA 33: ENVÍO CONSULTA SINCRONIZACIÓN
El ultimo parámetro de esta transacción se multiplica dependiendo de la cantidad de
transacciones a consultar, e igualmente se separan estos números por un |.
Captura de envío TX:
17|3C039714|20150729|0004|0349679|1565655|0349679|1565655
Formato de respuesta RX:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de transacciones consultadas
4 Bytes
Indica si la transacción fue sincronizada
1 Byte (N no, S sí)
TABLA 34: RESPUESTA CONSULTA SINCRONIZACION
Captura de respuesta RX:
17|0|0004|SSSS
4.6.15 Transacción de Informe al final del sorteo
El informe al final del sorteo también se realiza por loterías, nos retorna cada uno de los valores del
sorteo e indica específicamente los dineros que han sido debitados por ítem teniendo en cuenta
cantidad de ganadores.
87
Formato del envío TX:
Campo
Longitud
Id transacción
2 Bytes
Serial Máquina
8 Bytes
Usuario
4 Bytes
Fecha inicial de la consulta
14 Bytes
Fecha final del reporte
14 Bytes
Id lotería a consultar
2 Bytes
TABLA 35: INFORME AL FINAL DEL SORTEO TX
Captura de envío TX:
12|3C039714|4321|20150724000000|20150724235959|01
Formato de respuesta RX:
Campo
Longitud
Id transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
Nombre de la banca
Variable con un máximo de 31 Bytes
Fecha del reporte
14 Bytes
Nombre de la lotería del sorteo
Variable con un máximo de 31 Bytes
Números ganadores
Variable con un máximo de 15 Bytes
Tiquetes vendidos
7 Bytes con 2 ceros a la derecha para formato
Tiquetes ganadores
7 Bytes con 2 ceros a la derecha para formato
Total de venta
12 Bytes ( Con 2 decimales a la derecha)
Total de comisión
12 Bytes ( Con 2 decimales a la derecha)
Pagos realizados en el sorteo
12 Bytes ( Con 2 decimales a la derecha)
Dinero a recibir, lo que le debe devolver el vendedor
12 Bytes ( Con 2 decimales a la derecha)
Monto total de los tiquetes
12 Bytes ( Con 2 decimales a la derecha)
Deposito
12 Bytes ( Con 2 decimales a la derecha)
Total de ventas de terminales de la banca
12 Bytes ( Con 2 decimales a la derecha)
TABLA 36: RESPUESTA DEL INFORME AL FINAL DEL SORTEO
88
Captura de una respuesta exitosa RX:
12|0|Banca#00|20150730103738|Nac.Noche|12-45-88|0000300|0000300|000000015600|000000000
000|000006000000|-00005984400|000006000000|000000015600|000000015600
ILUSTRACIÓN 42: TIQUETE DEL INFORME AL FINAL DEL SORTEO
4.6.16 Recargas
Las recargas son una variación de un tipo de venta, por lo que eventualmente se utiliza el mismo
mapeo transaccional de una venta tanto para envío como para recepción, lo que se hace es cambiar la
utilización de los campos.
ILUSTRACIÓN 43: PARAMETRO DE RECARGAS
89
Esta trama contiene la siguiente cabecera:
Campo
Longitud
Id transacción "00" siempre venta online para recarga
2 Bytes
STAN(Consecutivo transacción)
6 Bytes
Cantidad de recargas(Siempre viaja 001)
3 Bytes
Serial Terminal
8 Bytes
Serial Sim Card
20 Bytes (Se rellena con ceros a la izquierda)
Valor en dinero de la recarga
9 Bytes ( Viajan 2 ceros a la derecha como
decimales)
Fecha y hora de venta
14 Bytes ( Importante si se hace OFFLINE)
Código generado por el POS
7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Código de cliente frecuente
5 Bytes
Separador de fin de cabecera
1 Byte @
TABLA 37: ENVÍO DE RECARGAS
Captura cabecera TX:
00|000017|001|3C039714|00008954871223654878|000002500|20150804184538|0000000|00000@
Después del separador de '@' se envía el detalle de cada venta:
Campo
Longitud
Id del operador de la recarga
2 Bytes
Id de juego, para este caso es una recarga
2 Bytes
Total de la recarga
7 Bytes( Viaja con 2 bytes a la derecha para decimales)
Número al que se debe hacer la recarga
Variable y depende de la longitud del teléfono
TABLA 38: DETALLE DEL ENVÍO DE RECARGAS
Captura del detalle de la venta:
28|06|0005600|3168828757
90
ILUSTRACIÓN 44: CONFIRMACIÓN DE RECARGA
Captura recarga completa con cabecera TX:
00|000017|001|3C039714|00008954871223654878|000002500|20150804184538|0000000|00000@
28|06|0005600|3168828757
Recepción exitosa RX:
Estructura de la respuesta del servidor:
Campo
Longitud
Id Transacción
2 Bytes
Código de Respuesta
1 Byte (0 exitosa, diferente de 0 es error)
STAN(Consecutivo de la transacción)
6 Bytes
Código de Autorización
10 Bytes ( Impreso en Código de barras)
Número de tiquete generado por el servidor
7 Bytes
Fecha y hora de la venta
14 Bytes
Fecha y hora del sorteo
8 Bytes
TABLA 39: RESPUESTA PARA RECARGAS
Captura de recepción exitosa RX:
00|0|000001|1234892974|1234567|20111228120000|20111228
91
ILUSTRACIÓN 45: TIQUETE DE RECARGA
4.7 Mensajería ISO 8583
El estándar para transacciones financieras fue implementado en la mensajería del sistema de descarga
remota. Con esto se contempla el manejo de datos sensibles y de estructuración de un protocolo a
partir de un estándar ISO.
El tiempo de desarrollo se minimiza implementando este protocolo debido a que los datafonos se
comunican con todos los sistemas de autorización (Host) utilizando este tipo de estándar. Con este
protocolo se toma la base de esta mensajería y se definen los detalles propios del sistema de descarga
y actualización.
ILUSTRACIÓN 46: MENSAJERIA DE DESCARGA REMOTA TX
92
En la Ilustración 46 se visualiza la trama ISO 8583 que envía la terminal hacia el servidor. En el
campo encerrado en color azul se muestra el terminal id, su función es identificar el dispositivo en el
servidor. El campo encerrado en color amarillo está el nombre del archivo el cual es validado en el
servidor. En el campo encerrado en color verde envía el paquete requerido, en este caso es el paquete
número 1 del archivo a descargar. Finalmente en el campo de color rojo aparece el tamaño máximo
del paquete solicitado por el usuario.
ILUSTRACIÓN 47: MENSAJERIA DE DESCARGA REMOTA RX
La recepción del paquete presenta el formato de la Ilustración 47, donde se visualiza en el campo
encerrado de color azul el terminal id (identificación del dispositivo), en el campo de color rojo
muestra el progreso de la descarga en este caso es de 1 de 125 paquetes.
El número de terminal es el campo clave en la detección del dispositivo correcto, además, el campo
que contiene el nombre de la aplicación proporciona el dato correcto de la aplicación que debe tener
instalado ese dispositivo.
El sumario de los campos privados definidos para envió y recepción de mensajería en formato ISO
8583 se describe en la siguiente tabla.
Tabla
Mensaje
A1
Paquete Solicitado
A2
Tamaño Máximo del paquete
93
A3
Progreso de la Descarga
!S
Nombre del archivo a descargar
K2
Paquete Descargado
41
Terminal ID
TABLA 40: TAGS CAMPO PRIVADO
5. RESULTADOS
5.1 Posibles Fallas o Causas de error
Perdida de los datos descargados dentro del datafono debido a perdida de alimentación,
reinicio inesperado o falla de comunicación.
Recepción errónea de la información.
Envío inadecuado de la información por parte del servidor.
Exceder la cantidad de datos que se pueden enviar a la impresora térmica.
Interrupción de procesos por duración de la batería.
Exceder los campos de respuesta en las consultas y los reportes.
Validación de ventas offline como total de ventas en el cierre.
Validación en la generación de reversos.
Error en la generación del código de venta del tiquete offline.
5.1.1 Perdida de los datos descargados
5.1.1.1 Pérdida de Alimentación
Los datafonos poseen dos tipos de alimentación dependiendo su uso, si es un dispositivo móvil su
fuente de alimentación principal es una batería de litio, por el contrario si es un dispositivo de
escritorio su alimentación es una fuente de poder externa.
Las baterías de litio se pueden agotar en cualquier momento siempre y cuando el datafono se
encuentre en operación. La fuente de poder está sujeta a desconexión por errores humanos o fallas en
la red de energía eléctrica.
5.1.1.2 Reinicio Inesperado
Los sistemas de comunicaciones poseen estándares y protocolos definidos; sin embargo, existe un
concepto llamado programación defensiva el cual tiene como objetivo garantizar el comportamiento
de todo elemento de una aplicación ante cualquier situación por incorrecta o imprevisible que esta
pueda parecer.
94
El sistema desarrollado tiene un control de excepciones definido el cual cumple con la función de
prevenir procesamiento erróneo de información y de esta manera hacer que el datafono se comporte
de una manera predecible pese a entradas y acciones inesperadas.
5.1.1.3 Falla de Comunicación
La red comunicación está sujeta disponibilidad del servicio y fallas de los equipos físicos, esto
provoca una interrupción del sistema que puede ser permanente o temporal.
5.1.2 Recepción errónea de la información.
La conexión entre dos dispositivos está expuesta a factores externos, ya que en la variedad de medios
ocurren diversos fenómenos que dificultan la adecuada transmisión. Se denomina error a la alteración
del mensaje recibido con respecto al mensaje transmitido.
Debido a algunos defectos en los medios de transmisión, pueden producirse errores en la información
transmitida. La medición de este error se realiza mediante la tasa de error y se expresa mediante la
relación entre el número de bits erróneos recibidos y el número total transmitido. Los errores tienden
a agruparse en ráfagas, en vez de ocurrir de manera aislada, este aspecto es una ventaja ya que facilita
la detección de los errores, de esta manera, afecta a un subconjunto de la información transmitida y es
posible reconstruir este subconjunto a partir del resto.
Al añadir unos bits a los paquetes transmitidos, de forma que identifique los errores cuando se
producen, es la manera como se pretende recibir la información con la menor cantidad de errores, así
poder ser corregida o simplemente detectada. El modo de obtener la redundancia determina el código
de protección frente a errores, hay códigos capaces de corregir n errores independientes de la posición
o solamente errores agrupados en un subconjunto de bits.
Para el sistema desarrollado se implementa el método de comprobación de redundancia cíclica (CRC)
y de retrasmisión de paquetes.
La verificación de información a través del CRC proporciona la posibilidad de validar cada uno de los
paquetes recibidos y descartar paquetes que sufren alteraciones en su trasmisión.
Del desarrollo apropiado de la verificación del dato CRC surge la necesidad de implementar el
método que haga posible la retrasmisión de un paquete con fallas. Este método de retrasmisión
segmenta la información en una cantidad finita de paquetes n, este valor permite solicitar el paquete
exacto que haya sufrido el error durante su trasmisión, con esto se asegura que la información a
almacenar en el dispositivo móvil es la esperada sin lugar a errores durante su verificación.
95
El dispositivo transmisor calcula el CRC añadiéndole al dato el número correcto de ceros. Los datos
se procesan utilizando matemática binaria. En el siguiente diagrama de flujo se muestra el proceso de
cálculo del CRC.
ILUSTRACIÓN 48: CALCULO DEL CRC
5.1.3 Envío inadecuado de la información por parte del servidor
Al existir un envío inadecuado de la información por parte del servidor pueden existir un número
elevado de excepciones no controladas por parte del datafono, sin embargo gracias al diseño del
protocolo de mensajería, es posible realizar mapeos previos de los campos a utilizar en cada
transacción. La posibilidad de existir desbordes de memoria es latente, para ello se ha utilizado un
método de errores controlados que permite por medio programación estructurada validar el tamaño de
la porción de memoria que recibe y la longitud de los datos a recibir. Se realiza una comparación entre
estos 2 datos y se procede a seguir el proceso correspondiente dependiendo si es exitosa o no la
validación.
96
5.1.4 Exceder la cantidad de datos que se pueden enviar a la impresora térmica
Entre las pruebas que se realizaron se observó que la cantidad de datos enviados a la impresora puede
ser muy alto, generalmente cuando se trata de reportes o apuestas con un número considerable de
jugadas. Este caso fue evidente al realizar un reporte de lista de números en rangos de fechas distantes,
para ello se han canalizado por código los procesos que generalmente podrían generar este tipo de
inconveniente. En este sentido se hace un conteo de los datos y se validan para enviar a imprimir lo
que se tiene primero en el buffer y volver a llenar con nuevos datos. Para evitar este inconveniente se
pensó en la posibilidad de enviar a imprimir de inmediato se recibía un carácter a imprimir, pero este
proceso agota la batería porque se debe estar abriendo y cerrando el periférico de salida (Impresora),
además de sobrecalentamiento del mismo, la impresora tiene un máximo de 1kB por impresión.
5.1.5 Interrupción de procesos por duración de la batería
En cuanto a este tipo de error, lo primero que se debe hacer es identificar los procesos más
importantes que realizan el sistema y observar que sucede si se cortan de manera súbita. Es claro que
los procesos más importantes son el envío y la recepción en una transacción además de la impresión
de tiquetes.
En el caso de envío y recepción el POS envía un reverso de la venta si esta no es percibida y procesada,
en cuanto a la impresión de tiquetes, si se corta en la mitad de una impresión, es normal que la venta
no se almacene en memoria, o si el papel se acaba, el tiquete es impreso por completo nuevamente. En
la descarga remota el datafono es capaz de recuperar el paquete de descarga donde estaba y comenzar
la retransmisión con el servidor.
5.1.6 Exceder los campos de respuesta en las consultas y los reportes
Es normal que por las cantidades de datos los campos que hacen la recepción de este tipo de
transacciones puedan ser desbordados, sobre todo si en ocasiones la cantidad de datos a recibir es
variable tal cual lo indica el protocolo desarrollado. Este tipo de sistema embebido no tiene la
facilidad de generar porciones de memoria adicional si viene información extra, para ello con ayuda
nuevamente de una programación defensiva, se ha utilizado la reserva dinámica de memoria que
posee el SDK para tratar esta situación de la manera más eficiente, lo que evita interrupciones en el
funcionamiento del software y mapeo ineficiente de la memoria en el dispositivo, es decir,
desperdicio de memoria.
5.1.7 Validación de ventas offline como total de ventas en el cierre
Al realizar un proceso de cierre es conveniente tener en cuenta que existan ventas offline para
empalmar con el inventario que tiene el receptor de transacciones. Ocasionalmente se observó que se
hacían cierres y se sincronizaban las ventas, sin embargo habían ventas que nunca lograban realizar la
sincronización, se observó que en algunas ocasiones al existir una conexión intermitente y lenta la
transacción era reversada por timeout, pero en el POS el reverso no era marcado con el mismo
97
consecutivo de salida de venta en el POS. Para esto se hizo revisión paso a paso del código con ayuda
de la herramienta de depuración que posee el SDK del POS, observando los valores que tomaba cada
espacio de memoria en este proceso y se corrigió puntualmente.
5.1.8 Validación en la generación de reversos y la sincronización
Los reversos según el entorno bancario deben ser ocasionados siempre que el tipo de transacción
conlleve al descuento o al abono de dineros a cuentas bancarias, en este caso la cuenta bancaria es el
servidor de Pérez Abreu, el cual valida cada una de las ventas que hacen las terminales y a su vez las
contrasta directamente sobre el sistema de cada lotería. Recordemos que tanto las recargas, como la
venta de apuestas, el batch y la sincronización tienen una forma similar en el envío de transacciones.
Las transacciones anteriormente citadas conllevan un reverso sino se percibe respuesta por parte del
servidor, sin embargo por la calidad de la red los reversos se convirtieron en el pan de cada día en
municipios alejados de cabeceras urbanas. Para controlar este tipo de inconvenientes y evitar que el
datafono se quede esperando la respuesta del servidor, se ha optado porque el reverso solo se envíe
siempre y cuando exista una ausencia de las respuestas para la venta de las apuestas, en el caso de las
recargas se habla de un reverso Host to Host, el cual es generado por el servidor de Pérez Abreu y
hace que el proceso del POS no tome vital importancia en este proceso.
Además a lo anterior se suma la cantidad de reversos que se podrían presentar sincronizando un lote
de apuestas offline, por ello también se implementó una transacción que hace consulta de
sincronización, y contrasta cada una de las ventas que se enviaron para sincronización en una sola
transacción sin esperar reverso de un posible timeout al sincronizar.
Los lotes de apuestas se sincronizan venta por venta sin esperar respuesta, solo al final se hace la
transacción de consulta que es de envío y recepción, y se marca en el lote ventas si su estado cambió
en el servidor, evitando a toda costa que las máquinas se queden inhibidas en un proceso de reverso
cuando la conexión es de baja calidad.
Por último se ha optado porque se operen las terminales con APN privado para evitar que las
transacciones viajen por un canal de comunicación público y se registre conexión lenta por la
demanda del mismo, lo que disminuye aún más el porcentaje de reversos presentados en las ventas de
hechas desde el POS.
5.1.9 Error en la generación del código de venta del tiquete offline
Erróneamente se implementó como primera medida marcar los tiquetes offline solo con la fecha
completa de venta, sin embargo se debe tener en cuenta que las ventas son simultaneas y pueden
existir errores de seguridad al jugar el tiquete, ya que se identifica por medio del código de barras su
autenticidad.
98
Para generar el código de barras se utiliza un código de seguridad que viaja en el detalle de la venta,
este código se genera con un algoritmo llamado "generarNumeroTicket" que realiza una serie de
pasos matemáticos que utiliza los siguientes datos a manera de ejemplo:
Serial de la máquina. 3C39714
Fecha de venta: 20150805
Hora de venta: 181615
Dando como resultado de su paso un 5958835437.
Al utilizar la fecha de la venta con la hora, la probabilidad de encontrar códigos similares es mínima,
incluyendo por supuesto el serial de la máquina. En este caso, este algoritmo también es validado y
contrasta con la lógica del servidor para verificar la autenticidad de un tiquete offline.
5.2 Descripción del Sistema de descarga remota
5.2.1 Almacenamiento
Cada paquete recibido es almacenado en un espacio de memoria con el objetivo de no perder
información descargada debido a fallas de comunicación, reinicios, etc. El almacenamiento de la
información permite reanudar el sistema a partir de cualquier punto intermedio si se ha visto
interrumpida.
5.2.2 Descompresión
La información descargada y almacenada debe ser sometida a un proceso de descompresión, el
método compresión y descompresión implementado en el sistema es el utilizado por el programa
7-zip bajo licencia GNU LGPL.
Este método de descompresión fue modificado de su versión original para su correcto funcionamiento
en espacios de memoria limitados como los tienen los datafonos.
Los siguientes son los pasos de configuración del datafono:
99
DESCARGA REMOTA
1.
2.
3.
4.
PARAMETROS DIAL.
NII
PARAMETROS IP.
CANT. DATOS
Se selecciona opción 3 para TCP - IP
.ILUSTRACIÓN 49: CONFIGURACIÓN DESCARGA REMOTA
La interfaz que muestra la configuración de la IP y el puerto del Host para Descarga Remota
de la siguiente manera:
IP INI
0.0.0.0
Nuevo Valor:
IKKLKL
.
.
.
Especificación de la IP servidor externo
ILUSTRACIÓN 50: CONFIGURACIÓN IP
Puerto Remoto 0000
Nuevo Valor:
IKKLKL
Especificación del Puerto servidor externo
ILUSTRACIÓN 51: CONFIGURACIÓN PUERTO
CONFIGURACION APN
1.
2.
3.
4.
CONFIGURACION MANUAL
CLARO
MOVISTAR
TIGO
ILUSTRACIÓN 52: TIPO DE OPERADOR
100
APN
IKKLKL
Nuevo Valor:
Especificación APN manualmente
ILUSTRACIÓN 53:
MANUAL
DE OPERADOR
Ilustración
20INGRESO
Ingresar
APN.
La siguiente tabla recopila los valores de tiempos y porcentajes que disminuyeron a la hora de
descargar la aplicación plana y comprimida.
Archivo
Tiempo
Tiempo descompresión
Tiempo
archivo 7z
archivo 7z
total Relación
del
tiempo en %
archivo 7z
Sin 7z
18:03 minutos
5:33 minutos
23:36 minutos
7z
5: 50 minutos
2:48 minutos
8:38 minutos
Disminuyo en
un 63.41 %
TABLA 41: DATOS PRÁCTICOS DESCARGA GPRS
Lote de
transacciones
offline
Método
sin
Método
con Tipo
implementación
implementación
de
de consulta
consulta
de
de
APN
Condiciones
% de Eficiencia
de cobertura
en
la
implementación
sincronización
30
1:58 Minutos
00:48 Minutos
Publico
Buena
59.43%
10
00:42 Minutos
00:17 Minutos
Publico
Buena
61,05 %
TABLA 42: IMPLEMENTACIÓN CONSULTA SINCRONIZACIÓN
Cantidad de
Máquinas
con
Máquinas
con Tipo de APN
Condiciones
% de Eficiencia
máquinas en
reverso
sin
reverso
con
de cobertura
en
República
método
de
método
de
Dominicana
implementación
implementación
de
de consulta
consulta
de
la
implementación
sincronización
960
288
58
Público
Aceptable
79.17%
TABLA 43: DISMINUCIÓN DEL PROCESO DE REVERSO
101
5.3 Variables del Sistema
El análisis del sistema y los resultados obtenidos se basan en una serie de ítems que indican los datos
en cifras medibles del sistema. Estos ítems se evalúan de 1 a 10 siendo 10 el nivel máximo. De
acuerdo a lo anterior la siguiente tabla muestra los valores otorgados a cada una de las variables del
sistema:
Variable
Puntaje
9
Observaciones
Con la adaptación de un APN privado se registran tiempos de 1,3
segundos por envío, utilizando un APN público se registran tiempos de 5 y
Velocidad de trasmisión
segundos. Notablemente ha mejorado este ítem.
10
La capacidad de la batería de 1800mAh hace que sea suficiente para
trabajar con todos los periféricos que posee el sistema embebido, duración
Duración de la batería
aproximada de 4300 transacciones de venta seguidas con su impresión
respectiva.
8
Los envíos son cortos y no generan un consumo significativo de datos, sin
embargo las respuestas en ocasiones son de una demanda alta de datos,
Consumo de datos por envío
(más de 2K en un solo envío), lo que genera un mayor costo en el consumo
de datos.
7
En Bogotá las pruebas han superado este ítem sin mayor dificultad, debido
a la infraestructura móvil que maneja la capital, sin embargo en lugares
Calidad de la comunicación
aparatados de la capital de Republica Dominicana se han presentado
inconvenientes de cobertura, lo que genera una calificación media de este
ítem.
8
Cantidad
de
Debido a la regular calidad en la comunicación en algunos puntos, se ha
optado por estrategias anteriormente mencionadas para disminuir la
reversos
latencia de los mismos, se ha pasado de un 30% de máquinas inhibidas en
generados
reversos por timeout a un 6% del total de las máquinas encontradas en
república dominicana.
9
Los tiempos han disminuido notablemente mientras existe una conexión
garantizada, el ejemplo puede ser un lote de 30 apuestas que se hace
Mejora en los tiempos de
offline, estas normalmente en buenas condiciones de cobertura toman
sincronización
unos 118 segundos en hacer todo el proceso, con la transacción
desarrollada esto apenas toma 48 segundos, lo que disminuye el tiempo de
transacción a menos de la mitad.
10
Tamaño
del archivo
de
La implementación de métodos de compresión de información optimiza el
rendimiento del sistema.
descarga remota
TABLA 44: VARIABLES DEL SISTEMA
102
Resultado de la valoración de las variables analizadas en el sistema desarrollado:
Total ítems evaluados:
Puntaje máximo:
Puntaje Obtenido:
7
70
61
El porcentaje de rendimiento del proyecto respecto a parámetros ideales es del 87.14%
Este porcentaje es excelente teniendo en cuenta que el parámetro de referencia es el ideal de todos
los ítems analizados, de allí que un porcentaje relativamente alto influye en la buena imagen que
entrega el desempeño el sistema desarrollado.
CONCLUSIONES
Es de vital importancia definir cada uno de los métodos de desarrollo que se deben emplear antes
de emprender cualquier proyecto de software. Esto toma una importancia mayor no solo al
momento de implementar el código del aplicativo, sino al momento de corregir errores y
encontrar posibles escenarios de fallos que nunca se contemplaron en una arquitectura inicial.
Sin lugar a dudas la automatización del sistema ha incrementado las ganancias de las casas de
apuestas, y como consecuencia se ha generado más empleo y no se está fugando el dinero de los
impuestos de República Dominica por apuestas clandestinas.
Es necesario tener en cuenta cuando tenemos una comunicación bidireccional que el tipo de
mensajería que se diseñe para hacer el proceso de comunicación debe ser dinámico, efectivo y
exitoso, la idea de generar conexión entre un servidor y un cliente es reproducir todo de la manera
más efectiva, sin mayor consumo de recursos y con dinamización por parte del aplicativo que
corre en el dispositivo cliente, para nosotros el sistema embebido POS.
Como se indica en temas anteriores, la cantidad de datos enviados a la impresora como periférico
externo del sistema embebido para la generación de comprobantes o tiquetes puede ser elevado,
alcanzando el límite máximo del dispositivo que es de 1KB. En este sentido se hace un conteo de
los datos y se validan para enviar a imprimir lo que se tiene primero en el buffer y volver a llenar
con nuevos datos, lo que se llama impresión en caliente, disminuyendo porcentualmente la
incertidumbre de perder la impresión del tiquete, evaluando las transacciones descritas en el
proceso.
Cuando un aplicativo cliente maneja montos de dinero significativos es importante invertir en
seguridad, de ello deriva la utilización de las terminales POS S90, las cuales vienen precedidas
por sus antecedentes bancarios, y por medio de la cual es posible emplear o utilizar cualquier
103
protocolo de cifrado que este a la altura de las circunstancias debido a su poderoso procesador
criptográfico.
Cuando se trabaja con un dispositivo que realiza sus procesos de comunicación inalámbrica
implicando las redes móviles de cada país, es importante verificar el funcionamiento de las
mismas redes. Esto en cuanto a cobertura, calidad de comunicación y capacidad de
comunicación, atenuando cada uno de estos problemas ya sea por una red acceso privada o
certificando la calidad de la red pública existente. Esto toma su mayor importancia teniendo en
cuenta que la comunicación inalámbrica es una variable del sistema, la cual al depender de
agentes externos al mismo código del software, puede afectar de manera significativa,
convirtiéndose en un problema tangible y jamás contemplado en el diseño previo.
Al utilizar métodos de compresión y descompresión de archivos se reduce en un porcentaje
considerable la cantidad de información transferida. Con esto se logra disminuir el tiempo que
toma el sistema para transferir la información a través de la red; no obstante, la etapa de
descompresión de información tiene un tiempo de procesamiento el cual viene limitado por
varios factores entre ellos están la cantidad de información a descomprimir, la tasa de
compresión, la velocidad de descompresión y la velocidad de almacenamiento.
El módulo de descarga remota permite actualizar cualquier tipo de información, esto indica que
posteriormente es posible implementar este sistema para otro tipo de aplicaciones y otro tipo de
dispositivos, por ejemplo descarga de parámetros adicionales o compresión del mismo ISO 8583.
Como se logra observar en los datos de descarga remota del aplicativo, con la implementación
del modulo se ha logrado que el tiempo de la actualización del aplicativo disminuya en un
63.41%.
El protocolo de comunicación desarrollado cumple a cabalidad con las tareas principales que se
han enunciado al comenzar el proyecto. Posteriormente se ha observado que en ocasiones el
consumo de datos es significativo en el momento en que se realizan las inicializaciones. En
ocasiones superan los 3KB, por ello es importante trabajar en una estrategia para comprimir estos
datos de la manera más adecuada. Debido a la implementación de la librería 7Z esto es posible
también hacerlo con los datos que viajan al servidor, pero esto también requiere de un sistema
complementario que sea capaz de interpretar lo que el POS envía comprimido, el sistema POS es
solo una pequeña parte del funcionamiento total del sistema apuestas en República Dominicana.
Es estrictamente necesario el desarrollo de una documentación adecuada y complementaria al
desarrollo que se ha llevado a cabo, por medio de la misma el usuario podrá dimensionar el
potencial y la eficiencia del desarrollo implementado, para ello se ha generado una manual de uso
del aplicativo correctamente especificado.
104
BIBLIOGRAFÍA
1) 7 Zip. (2012). 7 Zip. Recuperado el 24 de Julio de 2013, de www.7-zip.com
2) Almudena Días, P. M., & Rivas, J. (2007). Análisis de symbian OS para desarrolar
aplicaciones distribuidas sobre terminales GPRS. Málaga.
3) Alvarez, S. (18 de Mayo de 2006). desarrolloweb.com. Obtenido de desarrolloweb.com:
http://www.desarrolloweb.com/articulos/2477.php
4) Arias Guerrero, A. (2009). Propuesta de un plan para adquirir una solución tecnologica que
permita la administración y monitoreo de la red de cajeros automaticos del banco popular de
desarrollo comunal. San José, Costa Rica.
5) Barranco, M. R. (Junio de 1996). SOCKETS: COMUNICACIÓN ENTRE PROCESOS
DISTRIBUIDOS. Recuperado el 23 de Julio de 2013, de http://es.tldp.org/:
http://es.tldp.org/Universitarios/seminario-2-sockets.html
6) CAMPOS, J. R. (2009). ASPECTOS TECNICOS DE WCDMA EN LOS SISTEMAS
INALAMBRICOS. Caracas – Venezuela: Corp Banca.
7) Castillo, Y. A. (2014). Proyecto de Banca de Apuestas. Obtenido de Monografías.com:
http://www.monografias.com/trabajos101/proyecto-banca-apuestas/proyecto-banca-apuestas
.shtml
8) CCM. (Junio de 2014). La compresión de datos. Recuperado el 25 de Junio de 2013, de
Es.ccm.net: http://es.ccm.net/contents/714-la-compresion-de-datos
9) Christian Bettstetter, H.-J. V. (1999). DESCRIPCION DE GPRS SERVICIO DE RADIO DE
PAQUETES DE GENERALES Y EVOLUCION GLOBAL DE DATOS MEJORANDO EDGE.
munich, alemania.
10) Cisco Systems, Inc. (2007). CCNA Exploration 4.0 Aspectos básicos de networking.
11) Corporation, M. S. (2009). GPRS. Microsoft Corporation.
12) Crespo Martínez, L. M., & Candelas Herías, F. A. (1998). Introducción a TCP/IP - Sistema de
Transporte de Datos. Publicaciones de la Universidad de Alicante.
13) Cruz Lopez, E. J., Ramos Buitrago, J. C., & Eslava, H. J. (2007). Software para gestión y
administración de imágenes utilizando tecnología multimedia GSM. Bogotá.
14) Cuevas, J. A. (2007). Modulo didáctico de instrumentación electrónica implementado con
tecnología FPAA. Bogotá, Colombia.
15) Di Mare, A. (1997). Transferencia de archivos durante una conversación telefónica. San Jose
Costa Rica.
16) Digitalfotored.
(2014).
Glosario
GPRS.
http://www.digitalfotored.com/glosario/gprs.htm
Obtenido
de
digitalfotored.com:
105
17) Dunkels, A. (2006). The uIP Embedded TCP/IP Stack. Estocolomo: Swedish Institute of
Computer Science.
18) ENTEL. (12 de Abril de 2013). ¿Sabes lo que significa WCDMA? Obtenido de
http://comunidad.entel.cl/:
http://comunidad.entel.cl/internet/posts/sabes-lo-que-significa-wcdma
19) Escuela Politécnica Superior de Alcoy (España). (2014). Sistemas Embebidos: Innovando
hacia
los
Sistemas
Inteligentes.
Obtenido
de
semanticwebbuilder:
http://www.semanticwebbuilder.org.mx/es_mx/swb/Sistemas_Embebidos_Innovando_hacia
_los_Sistemas_Inteligentes_
20) Espinosa Peñeherrera, F. P., & Soto Arango, A. F. (2009). Pago electrónico a través de
teléfonos móviles. Guayaquil, Ecuador.
21) Forouzan, B. A. (2002). Transmisión de Datos y redes de comunicaciones 2 Ed.
McGraw-Hill.
22) Galeano, G. (2009). Programación de sistemas embebidos en C. Bogotá: AlfaOmega.
23) GSM World. (2010). GSM Technology: GPRS. Recuperado el 10 de Junio de 2013, de
http://www.gsmworld.com/technology/gprs.htm
24) Herramienta web para la enseñanza de comunicación. (2012). neo.lcc.uma.e. Obtenido de
neo.lcc.uma.e: http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/http.html
25) HK shangai group limited. (2001). Sierra Wireless WMP100 Intelligent Embedded Module
M2M GSM GPRS Modem . Recuperado el 10 de Junio de 2013, de
http://www.hkshanhai.net/sdp/503655/4/pd-2695572/6913098.html
26) Hypercom. (2 de Mayo de 2002). ISO8583. Phoenix, Arizona, USA.
27) John, C. (2009). T800 Software Development Training V1.0. Hong kong.
28) Kioskea. (Julio de 2013). kioskea. Recuperado el 25 de Julio de 2013, de
http://es.kioskea.net/contents/273-protocolos-ppp-y-slip-protocolo-punto-a-punto-y-protocol
o-de-li
29) L.Silva. (23 de Septiembre de 2011). http://www.enlinux.org/. Obtenido de
http://www.enlinux.org/: http://www.enlinux.org/puertos-y-servicios-en-gnulinux-centos/
30) Luz, S. d. (12 de Mayo de 2011). Redes Zone. Recuperado el 15 de Junio de 2012, de
http://www.redeszone.net/2011/05/12/sftp-y-ftps-diferencias-entre-sftp-y-ftps-para-la-transfe
rencia-segura-de-ficheros/#comments
31) Márquez, J. B. (2005). Transmisión de Datos. Mérida: Universidad de los Andes.
32) Navarro, G. (Junio de 2001). GPRS: el despegue de la Internet móvil. Recuperado el 10 de
Junio de 2013, de http://www.uoc.edu/web/esp/art/uoc/0105021/berbel_imp.html
106
33) Navarro, R. C. (2010). Instalación de Linux para ARM en sistemas empotrados. Granada,
España.
34) Oliva Mateos, A., & Sierra Collado, A. J. (Abril de 2006). Aplicación de Seguridad en
Servicios Web XML para dispositivos móviles mediante la implementación de un perfil
SAML.
35) PAX Technology Limited. (2013). Pax S90 Wireless Network. Obtenido de paxsz.com:
http://www.paxsz.com/en/product/index.aspx?n=119002001002&i=100000041686325
36) Picerno, J. M. (2010). Domótica para sistemas embebidos. Montevideo.
37) Prezi.com. (8 de Febrero de 2014). Prezi.com/Sistemas Embebidos. Obtenido de prezi.com:
https://prezi.com/qbau5mrpu1vv/sistemas-embibedos/
38) Rescorla, E., & Dick, K. (s.f.). Secure Auditing for SSL Transactions. working paper.
39) Sanchez, I.
G. (2010).
sites.google.com. Obtenido de
sites.google.com:
https://sites.google.com/site/ivangarciasanchez90/objetivos/gestion-tema-3/5o
40) Sitepro. (Abril de 2009). Prensario_Abril2009_Perez_Abreu. Obtenido de siteprocom:
www.siteprocom.ar/descargas/Notas/Prensario_Abril2009_Perez_Abreu.pdf
41) Sitiosargentina.com. (2009). sitiosargentina.com. Obtenido de sitiosargentina.com:
http://www.sitiosargentina.com.ar/webmaster/cursos%20y%20tutoriales/puerto.htm
42) Universidad de Oviedo - Ingeniería de sistemas y automatica. (2006). El Protocolo TCP/IP.
Asturias, Oviedo.
43) Universidad tecnologica de Mixteca. (2009). Sistema de comunicaciones basado en Ethernet
para el control de sistemas empotrados. Ciudad de México: Diciembre.
44) Universitat oberta de Catalunya. (2013). uoc.edu. Obtenido
http://cv.uoc.edu/UOC/a/moduls/90/90_574b/web/main/m7/c1/1.html
45) uv.es.
(2011).
GPRS.
Obtenido
www.uv.es/~montanan/redes/trabajos/GPRS.do
de
de
uoc.edu:
www.uv.es:
46) Vásquez, J. M. (2002). SSL, Secure Sockets Layer y Otros Protocolos Seguros para el
Comercio Electrónico.
47) Vausseur, J.-P. (2012). Interconnecting smart objects with IP. Obtenido de
www.assembla.com:
https://www.assembla.com/spaces/EmsProjectBuildingAutomation/documents/czrepOx7mr
4B1racwqjQXA/download/czrepOx7mr4B1racwqjQXA
48) Zator.com.
(2011).
Números
de
http://www.zator.com/Internet/N_11.htm
puertos.
Obtenido
de
zator.com:
107
