1

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

2

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

3

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.

4

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.

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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).

13

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).

14

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).

15

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.

16

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

17

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.

18

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.

19

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

20

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)

21

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.

22

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).

23

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

24

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.

25

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).

26

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

27

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.).

28

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

29

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).

30

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}

31

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: permite el acceso a protocolos de más bajo nivel como el IP ( nivel de

red ).

Tipo SOCK_SEQPACKET: tiene las características del SOCK_STREAM pero además el

tamaño de los mensajes es fijo (Barranco, 1996).

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).

32

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.

33

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).

34

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).

35

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 Protocolo

de transporte de datos de la Unidad (TPDU).

La estructura correspondiente a los datos de aplicación consta de tres partes

fundamentales:

• 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 Autorización

02 Financiera

03 Archivo de actualización / transferencia

04 Reverso

05 Reconciliación de control

06 Administrativa

08 Gestión de red

Para los dígitos 3 y 4

00 Solicitud interactiva

10 Respuesta interactiva

36

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 ISO-

8583 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

37

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]

38

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.

39

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).

40

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.

41

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

42

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

43

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

44

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.

45

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:

46

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).

47

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).

48

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

49

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.

50

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.

51

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. Establecimiento de la conexión PPP.

2. Autenticación con el proveedor de telefonía y datos de navegación móvil.

3. Apertura del socket de comunicación TCP.

4. Envío de datos en PPP.

5. Liberación de recursos lógicos y físicos del proceso de comunicación TCP.

6. Liberación de los recursos utilizados por la conexión PPP.

Los parámetros de configuración del datafono son los siguientes:

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.

Modem 850/1900

Desea cambiar de bandas?

SI = ENTER NO = CLR

FRECUENCIA MODEM

Cambio de banda dependiendo del operador

ILUSTRACIÓN 13: CONFIGURACÍON BANDAS

ILUSTRACIÓN 14: CONFIGURACIÓN APN.

52

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.

Nuevo Valor:

User:

IKKLKL

Nuevo Valor:

APN

IKKLKL

Especificación APN manualmente

Usuario APN

Contraseña APN

ILUSTRACIÓN 15: INGRESAR APN

ILUSTRACIÓN 16: INGRESAR USUARIO SIN APN

ILUSTRACIÓN 17: INGRESAR CONTRASEÑA

53

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.

54

ILUSTRACIÓN 19: DIAGRAMA DE FLUJO PRINCIPAL

55

4.4 Diagrama de clases básicas del desarrollo

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.

ILUSTRACIÓN 20: DIAGRAMA DE CLASES

56

ILUSTRACIÓN 21: CASOS DE USO

57

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.

TX:

09

|

2a000206

|

0-1 Estado de inicialización: 0 no está inicializado, 1 ya ha inicializado el pos

Usuario:

Clave:

Login online

IKKLKL

ILUSTRACIÓN 22: LOGIN

58

|

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:

59

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

60

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

61

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

62

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

63

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'.

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.

ILUSTRACIÓN 23: MENU PRINCIPAL

64

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.

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

ILUSTRACIÓN 24: MODO OFFLINE

65

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

66

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

67

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

68

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)

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.

ILUSTRACIÓN 28: REVERSO EXITOSO

69

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

70

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.

71

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

72

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

73

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.

74

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

75

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

76

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.

77

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.

78

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

79

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.

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

1. NAC. TARDE

2. NAC. NOCHE

3. LEID. NOCHE

4. REAL TARDE

5. LTKA TARDE

ELIJA LOTERIA

IKKLKL

ILUSTRACIÓN 37: SELECCIONAR LOTERIA EN REPORTE PARCIAL

80

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

81

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:

82

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

83

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

84

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.

85

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

86

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.

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:

ILUSTRACIÓN 41: PANTALLA DE SINCRONIZACIÓN

87

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.

88

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

89

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

90

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

91

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

92

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

93

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

94

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.

95

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.

96

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.

97

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

98

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.

99

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:

100

.

La interfaz que muestra la configuración de la IP y el puerto del Host para Descarga Remota

de la siguiente manera:

1. CONFIGURACION MANUAL

2. CLARO

3. MOVISTAR

4. TIGO

CONFIGURACION APN

Nuevo Valor:

Puerto Remoto 0000

IKKLKL

Nuevo Valor:

. . .

IP INI 0.0.0.0

IKKLKL

1. PARAMETROS DIAL.

2. NII

3. PARAMETROS IP.

4. CANT. DATOS

DESCARGA REMOTA

Se selecciona opción 3 para TCP - IP

Especificación de la IP servidor externo

Especificación del Puerto servidor externo

ILUSTRACIÓN 49: CONFIGURACIÓN DESCARGA REMOTA

ILUSTRACIÓN 50: CONFIGURACIÓN IP

ILUSTRACIÓN 51: CONFIGURACIÓN PUERTO

ILUSTRACIÓN 52: TIPO DE OPERADOR

101

Ilustración 20 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

archivo 7z

Tiempo total

archivo 7z

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

implementación

de consulta de

sincronización

Método con

implementación

de consulta

Tipo de

APN

Condiciones

de cobertura

% de Eficiencia

en la

implementació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 en

República

Dominicana

Máquinas con

reverso sin

método de

implementación

de consulta de

sincronización

Máquinas con

reverso con

método de

implementación

de consulta

Tipo de APN Condiciones

de cobertura

% de Eficiencia

en la

implementación

960 288 58 Público Aceptable 79.17%

TABLA 43: DISMINUCIÓN DEL PROCESO DE REVERSO

Nuevo Valor:

APN

IKKLKL

Especificación APN manualmente

ILUSTRACIÓN 53: INGRESO MANUAL DE OPERADOR

102

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 Observaciones

Velocidad de trasmisión

9 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

segundos. Notablemente ha mejorado este ítem.

Duración de la batería

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

aproximada de 4300 transacciones de venta seguidas con su impresión

respectiva.

Consumo de datos por envío

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,

(más de 2K en un solo envío), lo que genera un mayor costo en el consumo

de datos.

Calidad de la comunicación

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

aparatados de la capital de Republica Dominicana se han presentado

inconvenientes de cobertura, lo que genera una calificación media de este

ítem.

Cantidad de reversos

generados

8 Debido a la regular calidad en la comunicación en algunos puntos, se ha

optado por estrategias anteriormente mencionadas para disminuir la

latencia de los mismos, se ha pasado de un 30% de máquinas inhibidas en

reversos por timeout a un 6% del total de las máquinas encontradas en

república dominicana.

Mejora en los tiempos de

sincronización

9 Los tiempos han disminuido notablemente mientras existe una conexión

garantizada, el ejemplo puede ser un lote de 30 apuestas que se hace

offline, estas normalmente en buenas condiciones de cobertura toman

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.

Tamaño del archivo de

descarga remota

10 La implementación de métodos de compresión de información optimiza el

rendimiento del sistema.

TABLA 44: VARIABLES DEL SISTEMA

103

Resultado de la valoración de las variables analizadas en el sistema desarrollado:

Total ítems evaluados: 7

Puntaje máximo: 70

Puntaje Obtenido: 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

104

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.

105

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. Obtenido de digitalfotored.com:

http://www.digitalfotored.com/glosario/gprs.htm

106

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

107

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 de uoc.edu:

http://cv.uoc.edu/UOC/a/moduls/90/90_574b/web/main/m7/c1/1.html

45) uv.es. (2011). GPRS. Obtenido de www.uv.es:

www.uv.es/~montanan/redes/trabajos/GPRS.do

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 puertos. Obtenido de zator.com:

http://www.zator.com/Internet/N_11.htm