Anda di halaman 1dari 107

APLICACION Y DESARROLLO DE PROTOCOLO DE COMUNICACIN MEDIANTE

SISTEMA EMBEBIDO (POS)

Johan Mauricio Prieto Vargas

UNIVERSIDAD DISTRITAL
Francisco Jos De Caldas

Facultad Tecnolgica

Bogot D.C.
Agosto del 2015

1
APLICACION Y DESARROLLO DE PROTOCOLO DE COMUNICACIN MEDIANTE
SISTEMA EMBEBIDO (POS)

Cdigo del Proyecto 201501273065

Johan Mauricio Prieto Vargas Cdigo: 20131273014

Monografa para optar por el ttulo de:


Ingeniero En Telecomunicaciones

Director:
Edward Jacinto Gmez

UNIVERSIDAD DISTRITAL
Francisco Jos De Caldas

Facultad Tecnolgica

Bogot D.C.
Agosto del 2015

2
APLICACION Y DESARROLLO DE PROCOLO DE COMUNICACIN MEDIANTE
SISTEMA EMBEBIDO (POS)

PAGINA DE APROBACIN

Observaciones

_____________________________________________________________

_____________________________________________________________

______________________________________________________________

______________________________________
Ingeniero Edward Jacinto Gmez
Director del Proyecto

_____________________________________
Ingeniero Jorge Eduardo Porras Bohada
Jurado 1

_____________________________________

Jurado 2

Fecha de Presentacin Agosto del 2015.

3
AGRADECIMIENTOS

Expreso mis agradecimientos a:

Cada una de las personas que han hecho posible que el da de hoy me encuentre preparando mi
proyecto de grado, que han hecho posible que uno de mis sueos de nio est a punto de convertirse
en realidad. A mis compaeros, por depositarme confianza en momentos decisivos y anteponernos a
un sin nmero de dificultades que se presentaron en el camino hasta el da 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 asesoras y dudas presentadas en la elaboracin de cada una de
las actividades acadmicas que comprenden esta carrera, que por m es considerada a partir de este
momento como un estilo de vida.

4
TABLA DE CONTENIDO

AGRADECIMIENTOS.................................................................................................................................... 4
GLOSARIO ................................................................................................................................................... 11
RESUMEN..................................................................................................................................................... 13
ABSTRACT ................................................................................................................................................... 14
INTRODUCCIN ......................................................................................................................................... 15
1 .PREELIMINAR ......................................................................................................................................... 16
1.1 Descripcin del problema.................................................................................................... 16
1.2 Justificacin ............................................................................................................................ 16
1.2.1 Impacto Social ............................................................................................................................. 16
1.2.2 Impacto Econmico ..................................................................................................................... 17
1.3 Metodologa Usada ................................................................................................................ 17
2. OBJETIVOS .............................................................................................................................................. 18
2.1 Objetivo General ...................................................................................................................... 18
2.2 Objetivos Especficos ............................................................................................................... 18
3. MARCO TERICO 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 Estndares de comunicacin, sistemas embebidos................................................................. 22
3.2.1 Comunicacin GPRS (Global Packet Service) .............................................................................. 22
3.2.2 WCDMA(Acceso mltiple por divisin de cdigo 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 Compresin y descompresin de datos ............................................................................... 38

5
3.8.1 Para que se comprimen datos? .............................................................................................. 38
3.8.2 Que es la compresin de datos? ............................................................................................ 38
3.8.3 Tipos de compresin ............................................................................................................... 38
3.8.4 Mtodos de compresin .......................................................................................................... 39
3.8.5 Compresin con perdida de datos ................................................................................................ 39
3.8.6 Compresin sin perdida de datos ................................................................................................. 40
3.8.7 Formato 7z .................................................................................................................................. 40
3.8.8 Algoritmo LZMA .......................................................................................................................... 41
3.9 Apuestas en Repblica Dominicana ......................................................................................... 41
3.10 Descripcin y definicin de la red a utilizar. .......................................................................... 44
3.10.1 Definicin del mtodo de transmisin 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. DISEO DE PROTOCOLO DE COMUNICACIN Y DESARROLLO DE LGICA SOBRE
SISTEMA EMBEBIDO ................................................................................................................................. 48
4.1 TCP IP ................................................................................................................................... 49
4.2 GPRS ................................................................................................................................... 50
4.3 Diagrama de flujo del desarrollo completo (Con protocolo de comunicacin implcito) ........ 53
4.4 Diagrama de clases bsicas del desarrollo................................................................................ 55
........................................................................................................................................................ 55
4.5 Diagrama de casos de uso ...................................................................................................... 55
4.6 Transacciones implementadas ................................................................................................ 57
4.6.1 Login-Inicializacin....................................................................................................................... 57
4.6.2 Transaccin de venta ..................................................................................................................... 63
4.6.3 Transaccin de reversin ............................................................................................................... 67
4.6.4 Transaccin de anulacin .............................................................................................................. 68
4.6.5 Transaccin de Batch Upload ........................................................................................................ 70

6
4.6.6 Transaccin de lista de nmeros .................................................................................................... 70
4.6.7 Transaccin de consulta de ventas ............................................................................................... 73
4.6.8 Transaccin de pagos ..................................................................................................................... 76
4.6.9 Transaccin de consulta de tiquetes ............................................................................................... 77
4.6.10 Transaccin de cierre de ventas ................................................................................................... 78
4.6.11 Transaccin de Reporte Parcial ................................................................................................... 79
4.6.12 Transaccin de consulta de tiquetes ganadores ................................................................ 81
4.6.13 Transaccin de consulta de cierre por fecha ................................................................................ 83
4.6.14 Transaccin de sincronizacin ..................................................................................................... 84
4.6.15 Transaccin de Informe al final del sorteo .......................................................................... 87
4.6.16 Recargas .................................................................................................................................... 89
4.7 Mensajera 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 Prdida de Alimentacin ............................................................................................ 94
5.1.1.2 Reinicio Inesperado.................................................................................................... 94
5.1.1.3 Falla de Comunicacin............................................................................................... 95
5.1.2 Recepcin errnea de la informacin. ............................................................................................ 95
5.1.3 Envo inadecuado de la informacin por parte del servidor ........................................................... 96
5.1.4 Exceder la cantidad de datos que se pueden enviar a la impresora trmica .................................... 97
5.1.5 Interrupcin de procesos por duracin de la batera ....................................................................... 97
5.1.6 Exceder los campos de respuesta en las consultas y los reportes ................................................... 97
5.1.7 Validacin de ventas offline como total de ventas en el cierre ...................................................... 97
5.1.8 Validacin en la generacin de reversos y la sincronizacin ......................................................... 98
5.1.9 Error en la generacin del cdigo de venta del tiquete offline ....................................................... 98
5.2 Descripcin del Sistema de descarga remota ........................................................................... 99
5.2.1 Almacenamiento ............................................................................................................................ 99
5.2.2 Descompresin .............................................................................................................................. 99
5.3 Variables del Sistema .............................................................................................................. 102
CONCLUSIONES ....................................................................................................................................... 103
BIBLIOGRAFA .......................................................................................................................................... 104

7
LISTA DE TABLAS
Tabla 1: ALGUNOS PUERTOS CONOCIDOS ............................................................................................................. 30
Tabla 2: CAMPOS ISO 8583 ........................................................................................................................................36
Tabla 3: METODOS DE COMPRESIN 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: ENVO DE ANULACIN .............................................................................................................................. 69
Tabla 12: RESPUESTA DE ANULACIN..................................................................................................................... 69
Tabla 13: ENVO DE BATCH.......................................................................................................................................71
Tabla 14: CABECERA LISTA NMEROS..................................................................................................................... 71
Tabla 15: DETALLE DE RESPUESTA LISTA NMEROS............................................................................................. 72
Tabla 16: ENVO DE CONSULTA ................................................................................................................................ 74
Tabla 17: RESPUESTA DE CONSULTA ....................................................................................................................... 75
Tabla 18: ENVO DE PAGOS .......................................................................................................................................76
Tabla 19: RESPUESTA DE PAGOS .............................................................................................................................. 76
Tabla 20: ENVO CONSULTA TIQUETES ................................................................................................................... 77
Tabla 21: ENVO DE CIERRE .....................................................................................................................................78
Tabla 22:RESPUESTA DEL CIERRE............................................................................................................................ 78
Tabla 23: REPORTE PARCIAL ENVO ........................................................................................................................ 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: ENVO DE CIERRE POR FECHA ................................................................................................................ 83
Tabla 29: RESPUESTA DE CIERRE POR FECHA .......................................................................................................83
Tabla 30: ENVO DE SINCRONIZACIN .................................................................................................................... 85
Tabla 31: DETALLE DEL ENVO EN SINCRONIZACIN ........................................................................................... 85
Tabla 32: RESPUESTA DE SINCRONIZACIN ...........................................................................................................86
Tabla 33: ENVO CONSULTA SINCRONIZACIN ......................................................................................................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: ENVO DE RECARGAS ................................................................................................................................ 90
Tabla 38: DETALLE DEL ENVO DE RECARGAS.......................................................................................................90

8
Tabla 39: RESPUESTA PARA RECARGAS ................................................................................................................... 91
Tabla 40: Tags CAMPO PRIVADO ............................................................................................................................... 94
Tabla 41: DATOS PRCTICOS DESCARGA GPRS ................................................................................................... 101
Tabla 42:IMPLEMENTACIN CONSULTA SINCRONIZACIN................................................................................ 101
Tabla 43: DISMINUCIN DEL PROCESO DE REVERSO ........................................................................................ 101
Tabla 44:VARIABLES DEL SISTEMA......................................................................................................................... 102
LISTA DE ILUSTRACIONES
Ilustracin 1: TERMINAL PAX S90 .............................................................................................................................. 19
Ilustracin 2: ARQUITECTURA GPRS ........................................................................................................................ 23
Ilustracin 3: GPRS PROTOCOLO DE SEGUNDA GENERACIN ............................................................................25
Ilustracin 4. WCDMA VS CDMA ................................................................................................................................ 26
Ilustracin 5: OSI VS TCP/IP .......................................................................................................................................26
Ilustracin 6: CABECERA TCP....................................................................................................................................28
Ilustracin 7: POINT TO POINT PROTOCOL ............................................................................................................. 32
Ilustracin 8: SISTEMA PUNTO A PUNTO ................................................................................................................. 33
Ilustracin 9: FTP ........................................................................................................................................................ 34
Ilustracin 10: COMPRESIN Y DESCOMPRESIN DE ARCHIVOS ........................................................................38
Ilustracin 11: COMPRESON SIMTRICA................................................................................................................. 39
Ilustracin 12:ESQUEMA TCP ....................................................................................................................................50
Ilustracin 13:CONFIGURACON BANDAS................................................................................................................ 51
Ilustracin 14: CONFIGURACIN APN. ..................................................................................................................... 51
Ilustracin 15: INGRESAR APN ...................................................................................................................................52
Ilustracin 16: INGRESAR USUARIO SIN APN ...........................................................................................................52
Ilustracin 17: INGRESAR CONTRASEA .................................................................................................................. 52
Ilustracin 18: DIAGRAMA DE FLUJO CONEXIN GPRS ........................................................................................ 53
Ilustracin 19: DIAGRAMA DE FLUJO PRINCIPAL ...................................................................................................54
Ilustracin 20: DIAGRAMA DE CLASES ..................................................................................................................... 55
Ilustracin 21: CASOS DE USO ...................................................................................................................................56
Ilustracin 22: LOGIN ................................................................................................................................................. 57
Ilustracin 23: MENU PRINCIPAL .............................................................................................................................. 63
Ilustracin 24: MODO OFFLINE.................................................................................................................................64
Ilustracin 25: GRILLA ................................................................................................................................................ 65
Ilustracin 26: VENTA APUESTA.................................................................................................................................67
Ilustracin 27: TIQUETE DE VENTA........................................................................................................................... 67
Ilustracin 28: REVERSO EXITOSO ............................................................................................................................ 68
Ilustracin 29: CAMPO DE ANULACIN ................................................................................................................... 69
Ilustracin 30: MENU CONSULTAS ............................................................................................................................ 71
Ilustracin 31: PARAMETROS DE CONSULTAS .........................................................................................................72
Ilustracin 32:TIQUETE DE LISTA DE NMEROS ....................................................................................................73
Ilustracin 33: PARAMETROS DE REPORTE ............................................................................................................. 75
Ilustracin 34: TIQUETE CONSULTA GENERAL .......................................................................................................75

9
Ilustracin 35: CONSULTA DE TIQUETES ................................................................................................................. 77
Ilustracin 36: PANTALLA DE CIERRE ....................................................................................................................... 79
Ilustracin 37: SELECCIONAR LOTERIA EN REPORTE PARCIAL ............................................................................79
Ilustracin 38: TIQUETE DE REPORTE PARCIAL .....................................................................................................80
Ilustracin 39: REPORTE DE TIQUETES GANADORES ............................................................................................ 82
Ilustracin 40: REPORTE DE CIERRE POR FECHA ..................................................................................................84
Ilustracin 41: PANTALLA DE SINCRONIZACIN .....................................................................................................86
Ilustracin 42: TIQUETE DEL INFORME AL FINAL DEL SORTEO ...........................................................................89
Ilustracin 43: PARAMETRO DE RECARGAS ............................................................................................................. 89
Ilustracin 44: CONFIRMACIN DE RECARGA ........................................................................................................91
Ilustracin 45: TIQUETE DE RECARGA ..................................................................................................................... 92
Ilustracin 46: MENSAJERIA DE ESCARGA REMOTA tx ........................................................................................... 92
Ilustracin 47: MENSAJERIA DE DESCARGA REMOTA RX ....................................................................................... 93
Ilustracin 48: CALCULO DEL CRC ........................................................................................................................... 96
Ilustracin 49: CONFIGURACIN DESCARGA REMOTA ........................................................................................ 100
Ilustracin 50: CONFIGURACIN IP ....................................................................................................................... 100
Ilustracin 51: CONFIGURACIN PUERTO ............................................................................................................ 100
Ilustracin 52: TIPO DE OPERADOR ....................................................................................................................... 100
Ilustracin 53: INGRESO MANUAL DE OPERADOR ............................................................................................... 101

10
GLOSARIO

GPRS Servicio general de paquetes va radioenlace.


TCP Protocolo de contro de transmision.
PPP Protocolo punto a punto.
SSL Capa de conexin 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 Enva y recibe.
SIM Modulo de identificacin de subscriptor.
IP Etiqueta numrica 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 mltiple por divisin de cdigo de banda ancha.
TFTP Protocolo de transferencia de archivos trivial.
DNS Sistema de Nombres de Dominio.
SNMP El Protocolo Simple de Administracin de Red.
Octeto Equivale a 8 bits, exactamente a 1 Byte.
API Interfaz de programacin de aplicaciones

11
Socket API para TCP/IP
Unix Sistema operativo portable, multitarea y multiusuario
Linux Sistema operativo de software libre y cdigo abierto.
Login Ingreso a una plataforma o sistema con credenciales.
Tag Etiqueta de lenguaje marcado.
AES Estndar de encripcin avanzado
Hash Tipo de funciones con una salida alfanumrica de longitud normalmente fija que
representa un resumen de toda la informacin.
SHA Algoritmo de hash seguro.
LZMA Algoritmo de compresin de Lempel-Ziv-Markov.
NFS Sistema de archivos de red.
LCP Protocolo de control de enlace.
Pale Juego de 4 dgitos en Repblica Dominicana.
Quiniela Juego de azar de 2 dgitos.
Berkeley Distribucin de software Berkeley de la universidad de california (BSD).

12
RESUMEN
La sistematizacin de procesos de compra y venta de gran variedad de tipos de servicios hace parte de
la evolucin que tenemos da a da gracias al conocimiento de nuevas tecnologas que se presentan en
nuestro diario vivir. Siempre hay una forma ms 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 conexin inalmbrica mediante los operadores de
celular disponibles en Repblica Dominicana. Este POS contara con perifricos de entrada y de salida
(teclado, impresora, pantalla, modem), lo que permitir un flujo de entrada y salida de datos muy
dinmicos, para procesar y registrar directamente esta informacin en el servidor principal de la
compaa, 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 mtodo de
pago ms utilizado por sus clientes, esto se debe al alto nivel de seguridad incorporado, la sencillez de
uso, la diversidad de medios de comunicacin, la variedad de distribuidores y la capacidad de
portabilidad del dispositivo. Lo anterior indica que no solo se desarrollarn las ventas en un mbito
ms seguro y eficiente, sino que probablemente la cantidad de personas que poseen el hbito de
apostar pueda aumentar debido a la posibilidad que existir de realizar otro tipo de transacciones por
este medio (POS).

13
ABSTRACT

The systematization of processes of Purchase and Sale of many different types of services are part of
the evolution that we have every day thanks to the knowledge of new technologies that arise in our
daily lives. There is always a more efficient and different form for to do many processes, in this case
we want to completely eliminate manual records on the subject of gambles, like forget the insecurity
that may exist in each of the transactions that daily made in a gambles system (Authenticity of the
voucher sales).

The idea is to use the system embedded that operates like a POS for making sales in any Location
including wireless connection using the Cellular Operators Available in the Dominican Republic.
This POS will have peripherals of input and output (keyboard, printer, screen, modem), allowing a
flow in and out of very Dynamic Data Processing and for to process and register directly that
information in the primary server for the company, which will automate the sales process and
consultations of the enterprise and will perform real-time sales.

Currently entities such as banks use POS (Point of Sale) as the method of payment used more for their
customers, this is due to the high level of security incorporated, simplicity of use, Media Diversity,
the Variety of distributors and the capacity of portability device. This indicates that not only sales will
develop in an environment safer and more efficient, otherwise that probably the number of persons
that have the habit of bet can increase because of the possibility to make another types of transactions
through of this device (POS).

14
INTRODUCCIN

El proyecto cuenta con el propsito de disear, construir e implementar un aplicativo que este en
capacidad de comunicarse con un sistema de venta, consulta y sincronizacin de Terminales Punto de
Venta (TPV) para una entidad de apuestas ubicada en Repblica Dominicana, con el fin de
sistematizar el mercado de los juegos de azar en dicho pas, adems 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 nmero 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 geogrfico en
donde est ubicado el dispositivo a actualizar.

Debido a la gran cantidad de terminales en produccin tambin se implement un mdulo de software


con la capacidad de actualizar la aplicacin principal de manera remota va GPRS. De este modo se
agiliza este proceso disminuyendo costos y tiempos.

15
1 .PREELIMINAR
1.1 Descripcin del problema

Debido a las apuestas ilegales en Repblica 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 ms capital para
la empresa promotora, sino que se tiene la posibilidad de generar muchos ms recursos pblicos 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 estarn garantizados y podrn apostar de
manera segura.

Es importante conocer que el despliegue que se hace al apostar con papel escrito es mucho ms denso
que el proceso que indica una transaccin electrnica, es claro que la idea de la automatizacin no
solo incluye seguridad en el proceso de venta, sino que garantiza la transparencia en la generacin de
la apuesta misma, debido a los datos de venta que proporciona el desprendible generado por el POS
en la apuesta.

1.2 Justificacin

La exigencia del mercado en cuanto a la automatizacin de procesos es cada vez ms 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 diseo de la mensajera, el proyecto ha generado un impacto exitoso en el mercado de las


apuestas, debido a la dinmica que se implemento en los protocolos de comunicacin entre servidor y
cliente, esta posibilidad permite que sea posible jugar cualquier tipo de lotera controlando
plenamente los horarios de cierre y sorteo de las mismas, adems del diseo 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 actualizacin remota de software, por medio de un mdulo 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 rpidamente y su puesta en marcha es ms
dinmica.

1.2.1 Impacto Social

El desarrollo de tecnologas sobre sistemas embebidos permite ampliar los conocimientos en este
campo y crear nuevas tcnicas para afrontar problemas de tipo tecnolgico, mejorando

16
acadmicamente los niveles de aprendizaje, posicionando a la Universidad Distrital Francisco Jos de
Caldas cmo ente investigadora en la aplicacin de nuevas tecnologas; de esta manera la apropiacin
del conocimiento de los estudiantes va mucho ms all de los limites que imponen tecnologas
convencionales.

El proyecto lejos de excluir a varios grupos sociales, incluye muchas ms personas, debido a la
generacin de empleo, ya que existirn muchos ms puntos de venta, consecuencia de la portabilidad
que posee el sistema embebido.

1.2.2 Impacto Econmico

Tener un control seguro del dinero que produce el negocio de las apuestas es indispensable, sobre
todo en un pas en auge como Repblica Dominicana ya que en sus inicios la falta de disponibilidad
de los medios de tecnologa de informacin, control y comunicacin avanzada, creaba una serie de
prdidas financieras, que poco a poco se ha ido corrigiendo.

Al hacer referencia acerca de una relacin costo beneficio nos adentramos en un tema bastante
interesante a nivel econmico, ya que sin perdidas ni dineros fraudulentos, las bancas nos dicen que
los beneficios son 1.34 veces ms que los costos. Este es un valor privilegiado tomando como base la
inversin que se debe realizar, teniendo en cuenta un periodo de tiempo de 5 aos, 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 mtodos clasicos (Castillo, 2014).

Con la inversin en tecnologa y seguridad la relacin 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 ms alto de consumidores.

1.3 Metodologa Usada

A continuacin se describe la metodologa 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
solucin de la situacin planteada. Se hace un alcance real del mismo y los posibles puntos
crticos que se plantean inicialmente. A partir de esta informacin se especificaran las
tecnologas y se procede a la consecucin del proyecto.

17
Se desarroll el mtodo por el cual la interfaz se conecte al servidor externo y realice un proceso
inicial de envi y recepcin de datos sin protocolo alguno para asegurar la conexin entre los
extremos de la transaccin de datos.

Planteamiento bsico acerca de los datos a enviar as como los campos del protocolo a utilizar en
los procesos de empaquetamiento y desempaquetamiento de informacin dinmica.

Seguimos con el desarrollo e implemento de una base para nuestro proyecto; Se implementarn
mdulos recurrentes que tiene la terminal para comenzar el desarrollo (captura de texto,
impresin en pantalla, impresin 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
cdigo sea facilmente migrado a otras plataformas.

En este paso control el comportamiento de todos los elementos que intervienen en la aplicacin
independientemente de lo incorrecta y poco probable que pueda llegar a ser la situacin. En
general se pretende multiplicar las comprobaciones que se realizan en todos lo mdulos 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
programacin 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

Disear e Implementar una aplicacin sobre un sistema embebido que realice transacciones masivas
con un servidor externo segn especificaciones del sistema.

2.2 Objetivos Especficos

Implementar mdulo de descarga remota para evitar despliegues ineficientes al momento de


actualizar el aplicativo en los puntos de venta.

18
Disear e implementar un comprobante fsico al momento de la venta que registra el TPV.
(ticket).

Desarrollar un manual de instrucciones para hacer un uso adecuado de la aplicacin


implementada.

Realizar procesos de transferencia bidireccional de datos con un servidor externo.

3. MARCO TERICO Y ESTADO DEL ARTE

3.1 Sistemas Embebidos


Los dispositivos FPGA o ARM permiten la implementacin 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 combinacin de
hardware y software de computadora, diseado para tener una funcin especfica. Por lo general los
sistemas embebidos se pueden programar directamente en el lenguaje ensamblador del
microcontrolador incorporado sobre el mismo o bien, utilizando algn compilador especfico, suelen
utilizarse lenguajes como C y C++ (Escuela Politcnica Superior de Alcoy (Espaa)., 2014).

Esta combinacin de software y hardware puede ser reemplazada en muchos casos por un circuito
integrado que realice la misma tarea. Lo que seala que una de las ventajas de los sistemas embebidos
es su flexibilidad, ya que a la hora de realizar alguna modificacin resulta mucho ms sencillo
modificar unas lneas de cdigo al software del sistema embebido que reemplazar todo el
circuito integrado.

ILUSTRACIN 1: TERMINAL PAX S90

19
Los sistemas embebidos suelen tener en una de sus partes una "computadora" con caractersticas
especiales conocida como microcontrolador que viene a ser el cerebro del sistema.
Este no es ms 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 diagnstico del sistema, adems cabe resear que el uso de sistemas embebidos en productos
complejos implica un desafo de la seguridad en TI para proteger la informacin contenida en el
sistema embebido y tambin la que es transmitida desde y hacia el dispositivo por redes privadas o
Internet. Por tanto cabe incluir funciones criptogrficas, diseo de protocolos y consultora en
anlisis y verificacin as como servicios de pruebas de seguridad y evaluaciones especficas
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 Amrica, debido a los altos
estndares de seguridad que maneja, al igual que la capacidad y calidad de comunicacin que
ofrece el modem frente a otro tipo de terminales o sistemas. La Terminal POS mvil S90 de PAX
ha sido diseada para ofrecer un rendimiento inalmbrico superior. Con mltiples opciones de
comunicacin 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) batera recargable, la S90 es una
de las terminales mviles ms populares con los comerciantes de hoy (PAX Technology Limited,
2013).
La S90 viene con un lector de tarjetas sin contacto incorporado, certificacin 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 Escner de Cdigo de barras
Conectividad USB & 3G
Gran capacidad en batera
GPRS (tambin doble SIM), CDMA, 3G

Especificaciones
Procesador:32-bit ARM 11
Comunicacin: GPRS / CDMA /3G (WCDMA)

20
Mdem (Opcional): Sync. (HDLC, hasta 9600bps), Async. (V.92, hasta 56kbps)
Fsico: Longitud: 199mm, Ancho: 87mm, Altura: 61.5mm
Peso:504 g con batera
Batera: Li-ion (iones de litio), 1800mAh, 7.4V
Lector de Cdigo de Barras (Opcional)
Scanner Cdigo de Barras 1D
Certificaciones: PCI PTS3.x, EMV L1 & L2, MasterCard Pay Pass, Visa Pay Wave, EMV
Contactless L1.
Puertos Perifricos: 1 x RS232, 1 x mini USB (OTG), 1 x Line (Opcional), 1 x cargador de
energa.
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: 0C a 50C (32F to 122F), temperatura en operacin -20C a 70C
(-4F a 158F), 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 alfanumricas, 8 teclas de funcin, 4 teclas ATM, 1 tecla de
Encendido/Apagado.
Impresora: Impresora Trmica, velocidad: 18 lneas por segundo, ancho rollo de papel /
dimetro: 58 mm / 38 mm
Lector de Tarjeta Magntica: 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 creacin e impresin 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. Tambin generan diversos reportes que ayudan en la gestin del negocio.
Los TPV se componen de una parte hardware (dispositivos fsicos) y otra de software (sistema
operativo y programa de gestin).

Principales Aplicaciones de los TPV:

Control de las unidades vendidas por cada operario, con la cual se le pueden aplicar medidas
de rendimiento.
Planificacin automtica de pedidos.
Anlisis de ventas segn el horario y la seccin.

21
Control de los fallos externos a travs de las devoluciones y el motivo de la devolucin.
Asignacin 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 diseado nicamente para oficinas, tal cual sucede con los ordenadores, en tanto que el POS ha
sido diseado para un ambiente de punto de venta de alto trfico. Son diferentes ambientes con
requerimientos diferentes.

3.2 Estndares de comunicacin, sistemas embebidos


Una red de comunicacin es la conexin entre dos o ms 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 debern tener el mismo esquema de conexin. Para que la
comunicacin sea satisfactoria deben contar con el mismo sistema de interconexin y el mismo
protocolo de red que permita tener una interoperabilidad.
Para construir aplicaciones que deban ejecutarse en red existen varios estndares, algunos de los
cuales se encuentran en la IEEE 802.

3.2.1 Comunicacin GPRS (Global Packet Service)

El protocolo de comunicacin GPRS es un estndar de comunicaciones inalmbrica basado en la


conmutacin de paquetes de datos sobre la misma red GSM de la telefona celular digital, con
modificaciones que implican una mayor velocidad y un mayor ancho de banda, est inmerso en la
tecnologa de red 2.5G (GSM World, 2010).

Mientras que la red GSM transmite voz y tiene un sistema de mensajera con capacidad para 160
bytes por mensaje (el GSM-SMS), GPRS permite transmitir voz y datos de forma simultnea.
Otras capacidades de GPRS son la transferencia de archivos, la navegacin en la Web, el correo
electrnico sin lmites y funciones de localizacin geogrfica (Digitalfotored, 2014).

Esta diversidad permite prever distintos tipos de terminales GPRS en funcin


de su utilidad: telfonos mviles, con posibilidad de enviar mensajes con texto e imgenes;
agendas electrnicas, que permiten transmitir voz y datos; ordenadores de mano, tipo PDA;
ordenadores porttiles, que utilicen un telfono GPRS para la conexin inalmbrica; o
dispositivos de comunicacin con sistemas de navegacin para automviles (Digitalfotored,
2014).

22
ILUSTRACIN 2: ARQUITECTURA GPRS

Debido al icremento del nmero de usuarios de telefona mvil y de usuarios de Internet era
inevitable que en algn momento ambos mundos se fusionasen (Voz y Datos). De all surge la
tecnologa GPRS.

El proceso de envi y recepcin de datos se realiza por fases separadas mediante los denominados
nodos de soporte los cuales re-direccionan la informacin a puntos de una red interactiva, como
puentes informticos, hasta llegar a su destino.

La conexin GPRS se realiza a travs 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 dinmica y temporalmente. El uso de este protocolo permite la asignacin de IP
dinmicamente a un dispositivo. Los canales o sockets a travs de los cuales se realiza esta
conexin, son generados dinmicamente, esto se hace con el fin de obtener siempre un canal de
comunicacin libre y no entrar en conflictos en la ruta de acceso a la red (Universitat oberta de
Catalunya, 2013).

Para establecer la conexin con la red es necesario pasar por un proceso de verificacin 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 negociacin con el proveedor de la tarjeta de Mdulo de Identificacin del Suscriptor
(SIM) , en este proceso el dispositivo enva los datos correspondientes a la direccin 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 conexin por protocolo TCP/IP
con la direccin solicitada por el usuario GPRS, si el proceso de conexin es exitoso, el agente
proveedor funcionara, en adelante, como un traductor de protocolos; convirtiendo los datos que son

23
enviados por el MODEM GPRS en protocolo PPP, a datos enviados mediante protocolo TCP/IP
dirigidos a la direccin IP solicitada (uv.es, 2011).

Los datos solicitados por el agente proveedor son bsicamente tres:


APN
Usuario GPRS
Contrasea GPRS

El APN (Access Point Name) es el nombre de punto de acceso el cual contiene una direccin IP a la
cual se puede conectar, un punto de configuracin y una opcin particular para el MODEM.

Estos APN corresponden a las redes pblicas de estos operadores, sin embargo estos agentes poseen
APN privados los cuales corresponden a canales de comunicacin de acceso restringido.

El protocolo de conexion al operador de telefonia movil exige un campo para contrasea y otro para
usuario, que en ocasiones por ser APN publico viajan vacios. Este tipo de datos nos brinda una
credencial de autenticacin para obtener una direccion IP desde el punto de acceso al dispositivo
movil.

Este sistema de conexin posee una caracterstica de cobro transaccional la cual se realiza por
cantidad de paquetes transmitidos y no cobro por tiempo de duracin de la conexin, es decir, un
dispositivo puede estar conectado a la red pero no tendr cobro alguno esta operacin debido a que los
recursos utilizados por el GPRS son liberados en el instante en que se detiene la transaccin de datos,
esto pasara siempre y cuando no exista un proceso de transmisin de datos en cualquier direccin por
el canal utilizado (uv.es, 2011).

Gracias a estas caractersticas, el servicio GPRS est dirigido principalmente a aplicaciones


interactivas las cuales presentan una densidad de transmisin de datos baja, lo cual disminuye los
recursos utilizados por el usuario, disminuyendo as los costos de operacin de la aplicacin; En
general este sistema aplica para cualquier proceso de transmisin de datos intermitente (uv.es, 2011).

A continuacin se describen algunas de las principales caractersticas de la red GPRS:

Velocidad de transferencia de hasta 144 Kbps.


Conexin permanente.
Pago por cantidad de informacin transmitida, no por tiempo de conexin.

24
ILUSTRACIN 3: GPRS PROTOCOLO DE SEGUNDA GENERACIN

3.2.2 WCDMA(Acceso mltiple por divisin de cdigo de banda ancha)

Este tipo de estandar hace parte de la 3er generacin 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 tecnologa mvil que aumenta las tasas de transmisin de datos de los sistemas GSM
utilizando la interfaz area CDMA en lugar de TDMA (Acceso Mltiple por Divisin de Tiempo).

Esta entrega velocidades de transmisin de datos mucho ms altas en dispositivos


inalmbricos mviles y porttiles que las ofrecidas hasta el momento (puede alcanzar velocidades de
hasta 2 Mbps para voz, video, datos y transmisin de imgenes).

Tanto la tecnologa WCDMA como la HSDPA pertenecen a la red 3G. La diferencia es que esta
ltima corresponde a la tecnologa utilizada para efectuar la optimizacin en la descarga de datos a
travs 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 tcnica de duplexacin FDD, utiliza muy eficientemente el espectro de
radio disponible, mediante la reutilizacin de cada celda.

Los enlaces desde la red de acceso WCDMA y en el ncleo de red GSM utilizan un protocolo de
transmisin ATM de mini-celdas, conocido como Capa de Adaptacin ATM 2 (AAL2).

WCDMA usa una tasa de chip de 4.096 Mcps. Entre los ltimos estudios sobre WCDMA estn:
Cancelacin de Interferencia, Cancelacin de Interferencia Gradual, Gerencia de Recurso Dinmico
en Sistemas Multimedia Inalmbricos, Tcnicas de Codificacin, entre otros (CAMPOS, 2009).

25
ILUSTRACIN 4. WCDMA VS CDMA

3.3 TCP/IP

Es un conjunto de reglas generales de diseo e implementacin de protocolos de red especficos para


permitir que un equipo pueda comunicarse en una red. TCP/IP provee conectividad de extremo a
extremo especificando como los datos deberan ser formateados, direccionados, transmitidos,
enrutados y recibidos por el destinatario. Existen protocolos para los diferentes tipos de
servicios de comunicacin entre equipos (Sanchez, 2010).

TCP/IP tiene cuatro capas de abstraccin segn se define en el RFC 1122. Esta arquitectura de capas
a menudo es comparada con el Modelo OSI de siete capas.

ILUSTRACIN 5: OSI VS TCP/IP

26
Caracteristicas:
Protocolo IP enrutado de la capa 3.
Funcionalidad extremo a extremo en la capa 4.
TCP/IP se usa como protocolo de acceso a Internet y para interconectar dispositivos de redes
corporativas.
El conjunto de protocolos TCP no solo incluye especificaciones de capa 3 y 4, sino tambin
especificaciones para aplicaciones comunes, como correo electrnico, emulacin de terminal
y transferencia de archivos.
Transferencia de archivos: TFTP, FTP, NFS.
Correo electrnico: SMTP.
Login remoto: TELNET Y RELOGIN.
Administracin de red: SNMP.
Administracin de nombres: DNS.

Este modelo se cre a principios de la dcada de los setenta y se conoce con el nombre de modelo de
Internet. Define cuatro categoras de funciones que deben tener lugar para que las comunicaciones
sean exitosas.

Un proceso completo de comunicacin incluye estos pasos:

1. Creacin de datos a nivel de la capa de aplicacin del dispositivo final origen.


2. Segmentacin y encapsulacin de datos cuando pasan por la stack de protocolos en el dispositivo
final de origen.
3. Generacin de los datos sobre el medio en la capa de acceso a la red de la stack.
4. Transporte de los datos a travs de la red de internet, que consiste de los medios y de cualquier
dispositivo intermediario.
5. Recepcin de los datos en la capa de acceso a la red del dispositivo final de destino.
6. Desencapsulacin y rearmado de los datos cuando pasan por la stack en el dispositivo final.
7. Traspaso de estos datos a la aplicacin de destino en la capa de aplicacin del dispositivo final de
destino (Cisco Systems, Inc, 2007).

Las funciones de las diferentes capas son las siguientes:

Capa de acceso a la red: Especfica 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 transmisin.
Capa de aplicacin: incorpora aplicaciones de red estndar (Telnet, SMTP, FTP, etc.).

27
ILUSTRACIN 6: CABECERA TCP

Puerto origen: Nmero de puerto que llama (16 bits).

Puerto destino: Nmero del puerto al que se llama (16 bits).

Nmero de secuencia: Nmero usado para garantizar la correccin en la secuencia de la llegada de


datos(32 bits).

Nmero de acuse de recibo: Siguiente octeto TCP esperado(4 bits).

Reservado: Fijado en 0(6 bits).

Bits de cdigo: Funciones de control, como el establecimiento y la finalizacin de una sesin(6 bits).

Ventana: Nmero de octetos que el dispositivo espera aceptar (16) bits.

Suma de comprobacin: Suma de comprobacin de cabecera y campos de datos (16 bits).

Urgente: Indica el final de los datos urgentes(16 bits).

Opciones: Algo ya definido, tamao mximo 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 ms puertos. Un puerto es un nmero de 16 bits, usado por el

28
protocolo HOST TO HOST para identificar a qu protocolo de ms alto nivel o programa de
aplicacin (proceso) debe entregar los mensajes de entrada (Dunkels, 2006).

El puerto es una numeracin lgica que se asigna a las conexiones, tanto en el origen como en el
destino. No tiene ninguna significacin fsica.

En una URL (Universal Resource Locator) los puertos se denotan con ':' a continuacin del nombre de
la mquina, por ejemplo http://www.alerta-antivirus.es:80/index.html quiere decir pedir el
documento 'index.html' mediante http conectndose 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 electrnico, 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
caractersticas de los sistemas conectados, y creando bases de datos con estas. Cuando se descubre
una vulnerabilidad, estn en disposicin de atacar rpidamente a las mquinas que se sabe que son del
tipo vulnerable.

Un puerto de red es una interfaz para comunicarse con un programa a travs de una red. Un puerto
suele estar numerado. La implementacin del protocolo en el destino utilizar ese nmero para
decidir a qu programa entregar los datos recibidos. Esta asignacin de puertos permite a una
mquina establecer simultneamente diversas conexiones con mquinas distintas, ya que todos los
paquetes que se reciben tienen la misma direccin, pero van dirigidos a puertos diferentes (Zator.com,
2011).

Los nmeros 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 asignacin, la cual cre tres categoras:

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 aplicacin. Existe una lista
publica en la web del IANA donde se puede ver qu protocolo usa cada uno de ellos
Los comprendidos entre los nmeros 49152 (C000 en hexadecimal) y 65535 (FFFF en
hexadecimal) son denominados dinmicos o privados, porque son los usados por el sistema
operativo cuando una aplicacin tiene que conectarse a un servidor y por tanto necesita un
puerto por donde salir (L.Silva, 2011).

29
Como algunos programas de ms alto nivel son protocolos por s mismos, estandarizados en la
familia de protocolos TCP/IP, tales como telnet y ftp, usan el mismo nmero de puerto en todas las
realizaciones de TCP/IP. Aquellos nmeros de puerto "asignados" se denominan puertos
bien-conocidos y las aplicaciones estndares servicios bien-conocidos (Universidad de Oviedo -
Ingeniera de sistemas y automatica, 2006).

La confusin debida a que dos aplicaciones diferentes intentan usar los mismos nmeros de puerto
sobre un host se evita escribiendo esas aplicaciones para pedir un puerto TCP/IP disponible. Puesto
que este nmero de puerto se asigna dinmicamente, debe diferir de una invocacin de una aplicacin
a la prxima.

Algunos de los puertos conocidos ms 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 direccin de socket es la tripleta: {protocolo,
direccin-local, proceso-local}.En la familia TCP/IP, por ejemplo: {tcp, 193.44.234.3, 12345}

Una conexin es el enlace de comunicacin entre dos procesos, una asociacin es la quntupla que
especifica completamente los dos procesos que comprende una conexin:
{protocolo, direccin-local, proceso-local, direccin-externa, proceso-externo}

En la familia TCP/IP, por ejemplo:

{tcp, 193.44.234.3, 1500, 193.44.234.5, 21}

30
Los sockets son puntos de comunicacin entre procesos que permiten que un desarrollo se comunique
con otro desarrollo, incluso estando estos en distintas mquinas. Esta caracterstica de
interconectividad entre mquinas 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,
implementndose las utilidades de interconectividad de este Sistema Operativo ( rlogin, telnet, ftp,
etc. ) usando sockets (Barranco, 1996).

Un socket es al sistema de comunicacin entre ordenadores lo que un buzn o un telfono es al


sistema de comunicacin entre personas: un punto de comunicacin entre dos agentes por el cual se
puede emitir o recibir informacin. La forma de referenciar un socket por los procesos implicados es
mediante un descriptor del mismo tipo que el utilizado para referenciar ficheros.

La comunicacin entre procesos a travs de sockets se basa en la filosofa CLIENTE-SERVIDOR, un


proceso en esta comunicacin actuar de servidor creando un socket cuyo nombre conocer el
proceso cliente, el cual podr "hablar" con el servidor a travs de la conexin con dicho socket
nombrado (Barranco, 1996).

Tipos de sockets:

Tipo SOCK_DGRAM: sockets para comunicaciones en modo no conectado, con envo de


datagramas de tamao 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 vas y con
tamao variable de los mensajes de datos. Por debajo, en dominios Internet, subyace el
protocolo TCP.

Tipo SOCK_RAW: permite el acceso a protocolos de ms bajo nivel como el IP ( nivel de


red ).

Tipo SOCK_SEQPACKET: tiene las caractersticas del SOCK_STREAM pero adems el


tamao de los mensajes es fijo (Barranco, 1996).

3.4 PPP ( Point to Point Protocol )

Generalmente a travs de una lnea telefnica pueden comunicarse un mximo de dos equipos
mediante un mdem, al igual que resulta imposible llamar a dos personas simultneamente utilizando
la misma lnea telefnica. Esto se denomina conexin punto a punto, es decir, una conexin entre dos
equipos reducida a su expresin ms sencilla: no es necesario compartir la lnea con diversos equipos,
uno habla y el otro responde alternativamente (Kioskea, 2013).

31
Se han desarrollado diversos protocolos de mdem. los primeros permitan una simple transmisin de
datos entre dos equipos. Luego, algunos de ellos contaron con control de errores y, con el crecimiento
de Internet, tambin contaron con la capacidad de asignar direcciones a equipos. De esta manera,
existen actualmente dos protocolos de mdem principales:

SLIP: un protocolo antiguo, con pocos controles.


PPP: El protocolo ms utilizado para acceder a Internet mediante un mdem. Permite asignar
direcciones a equipos.

El Protocolo punto a punto es un protocolo mucho ms desarrollado que SLIP (por ello lo est
reemplazando), en la medida en que transfiere datos adicionales ms adaptados a la transmisin de
datos a travs de Internet (la adicin 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 encapsulacin de datagramas, un protocolo LCP, Protocolo de control de vnculos,


que permite probar y configurar la comunicacin

Los datos encapsulados en una trama PPP se denominan paquetes. Estos paquetes generalmente son
datagramas, pero tambin pueden ser diferentes (de all la designacin especfica 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:

ILUSTRACIN 7: POINT TO POINT PROTOCOL

Los datos de relleno se utilizan para adaptar la longitud de la trama para ciertos protocolos.

A continuacin se indica cmo se lleva a cabo una sesin PPP (desde el comienzo hasta el fin):

Una vez que se cuenta con conexin se enva un paquete LCP.

En el caso de una solicitud de autenticacin del servidor, se puede enviar un paquete relacionado con
un protocolo de autenticacin (PAP, Protocolo de autenticacin de contrasea, o CHAP, Protocolo de
autenticacin por desafo mutuo o Kerberos).

Una vez que se establece la comunicacin, PPP enva informacin de configuracin mediante el
protocolo NCP.

32
Los datagramas que se van a enviar se transmiten como paquetes. En el momento de la desconexin,
se enva un paquete LCP para finalizar la sesin.

La mayora de las personas que no cuentan con lneas (cable o Ethernet) directamente conectadas a
Internet deben utilizar lneas telefnicas (la red ms utilizada) para conectarse. La conexin se realiza
mediante un mdem, un dispositivo que puede convertir datos digitales de un equipo en seales
analgicas (que pueden circular por lneas telefnicas mediante amplitud modulada o frecuencia
modulada, de la misma manera que la voz cuando se utiliza el telfono) (Kioskea, 2013).

Si se tiene en cuenta que slo comunican dos equipos y que la velocidad de la lnea telefnica es lenta
en comparacin con la de una red local, es necesario utilizar un protocolo que permita la
comunicacin estndar entre diferentes equipos con mdem, para no sobrecargar la lnea telefnica,
se denominan protocolos de mdem.

ILUSTRACIN 8: SISTEMA PUNTO A PUNTO

3.5 FTP (File Transfer Protocol)

Es un sistema de reglas de comunicacin que permite que dos dispositivos se comuniquen entre s
independientemente del sistema operativo que utilicen, haciendo posible enviar informacin o
descargar archivos especficos.

El protocolo de transferencia de archivos tambin proporciona caractersticas para controlar el acceso


de los usuarios. Cuando un usuario solicita la transferencia de un fichero, FTP establece una conexin
TCP con el sistema destino para el intercambio de mensajes de control. A travs de esta conexin se
puede transmitir el identificador y la contrasea del usuario, y el usuario puede especificar el fichero
y las acciones sobre l deseadas (Crespo Martnez & Candelas Heras, 1998).

33
ILUSTRACIN 9: FTP

Una vez que se aprueba la transferencia del fichero, se establece una segunda conexin TCP para la
transferencia de datos. El fichero se transmite a travs de esa conexin de datos, sin informacin
suplementaria o cualquier cabecera de la capa de aplicacin. Cuando la transferencia se completa, el
control de la conexin se utiliza para indicar el final y la posibilidad de aceptar nuevas rdenes de
transferencia (Crespo Martnez & Candelas Heras, 1998).

3.6 HTTP

El Protocolo de Transferencia de HiperTexto es un sencillo protocolo cliente-servidor que articula los


intercambios de informacin entre los clientes Web y los servidores HTTP. La especificacin
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 distribucin de informacin como el World
Wide Web (Herramienta web para la enseanza de comunicacin, 2012).

Desde el punto de vista de las comunicaciones, est soportado sobre los servicios de conexin 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 conexin de los clientes Web. Una vez que se establece la conexin, el
protocolo TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de
errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexin con
un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un mensaje
similar, que contiene el estado de la operacin y su posible resultado. Todas las operaciones pueden
adjuntar un objeto o recurso sobre el que actan; cada objeto Web (documento HTML, fichero
multimedia o aplicacin CGI) es conocido por su URL (Herramienta web para la enseanza de
comunicacin, 2012).

34
3.7 Protocolo ISO8583

ISO-8583 es un protocolo transaccional de empaquetamiento y transferencia de datos


propuesto para sistemas que intercambian transacciones electrnicas; este protocolo est orientado a
todo tipo de transacciones financieras en las cuales se vean implicadas tarjetas de crdito o cualquier
tarjeta de pago electrnico, 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
realizacin.

ISO-8583 consta de dos estructuras bsicas, la cabecera y los datos de aplicacin.

En la cabecera encontramos el tamao de los datos transmitidos y el Protocolo


de transporte de datos de la Unidad (TPDU).

La estructura correspondiente a los datos de aplicacin consta de tres partes


fundamentales:

El MTI
El Bitmap
Los elementos de datos

El tipo de mensaje (MTI) consta de cuatro (4) dgitos y se utiliza para definir el tipo de mensaje de la
transaccin. El primero y segundo dgito identifica la clase de mensaje. El tercer y cuarto dgito se
utiliza para identificar la funcin del mensaje y el modo de transmisin.

Definicin del tipo de mensaje:

para los dgitos 1 y 2:

01 Autorizacin
02 Financiera
03 Archivo de actualizacin / transferencia
04 Reverso
05 Reconciliacin de control
06 Administrativa
08 Gestin de red

Para los dgitos 3 y 4

00 Solicitud interactiva
10 Respuesta interactiva

35
20 Asesoramiento no interactivo

Algunos ejemplos de tipo de mensaje usualmente utilizados son:

0100 solicitud de autorizacin


0110 respuesta de solicitud de autorizacin

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 posicin en un campo de control. Este nos indica cuales son los campos
que deben ser ledos en la operacin transaccional. La presencia de un elemento de datos en un
mensaje especfico se indica con un (1), en el asigna la posicin, la ausencia de un elemento de datos
se indica con un cero (0) en la posicin 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 varan entre s en cuanto a tamao y tipo de datos soportados por cada uno, cada
campo posee un nombre, un formato y un tamao predeterminado (Hypercom, 2002).

A continuacin se muestra una tabla con la descripcin de cada uno de los campos involucrados en el
protocolo ISO 8583.

TABLA 2: CAMPOS ISO 8583

36
ATRIBUTOS: a (caracteres alfabticos), n (datos numricos), s (caracteres especiales), an-as--ns-ans
combinacin de los anteriores respectivamente, b (dato en formato binario), z (dato recibido de la
banda magntica).

Algunos ejemplos de campos establecidos en el protocolo ISO-8583 son:

Campo 3. processing code (cdigo de procesamiento):

El cdigo de procesamiento se utiliza en conjuncin con el tipo de mensaje para definir el tipo de
transaccin que se est enviado por el Terminal en el servidor.

Este campo tiene un tamao de 6 caracteres estticos los cuales deben ser nicamente de tipo
numrico, es decir, de 0 a 9. Ejemplo: [92 00 00]

Campo 41. Terminal ID (identificacin de la Terminal):

Este es el cdigo de identificacin nico del dispositivo, con este cdigo se identifica por parte del
servidor cual es el Terminal que est realizando la transaccin.

Campo para caracteres alfanumricos y especiales y tiene una longitud de 8 caracteres. Ejemplo:
[3f0010278]

Campo 60. uso privado:

No todos los campos tienen longitud especfica, 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 transmisin de datos, estos datos son propios de cada transaccin y se pueden enviar a
preferencia de la Terminal.

El campo 60 tiene longitud variable y soporta caracteres alfanumricos y especiales, el tamao


mximo de este campo es de 999 Bytes.

Cuando se utilizan campos de longitud variable usualmente se enva en las dos primeras posiciones
del campo la longitud en formato BCD con el fin de indicar al servidor cuantos Bytes se envan en
ese campo especifico. Ejemplo: [00 05 38 33 33 39 37]

37
3.8 Compresin y descompresin de datos

3.8.1 Para que se comprimen datos?

Actualmente, el poder de procesamiento de los procesadores se incrementa ms rpido que la


capacidad de almacenamiento y es ms veloz que los anchos de banda de las redes, porque estos
ltimos requieren cambios enormes en las infraestructuras de telecomunicacin.
Por lo tanto, para compensar esto, es ms comn el procedimiento de reducir el tamao de los datos al
explotar el poder de procesamiento de los procesadores, que incrementar la capacidad de
almacenamiento y de transmisin de datos (CCM, 2014).

3.8.2 Que es la compresin de datos?

La compresin consiste en reducir el tamao fsico de bloques de informacin. 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 compresin
(CCM, 2014).

La siguiente imagen muestra los pasos de compresin y descompresn de un archivo.

ILUSTRACIN 10: COMPRESIN Y DESCOMPRESIN DE ARCHIVOS

3.8.3 Tipos de compresin

La compresin fsica acta directamente sobre los datos; por lo tanto, es cuestin de
almacenar los datos repetidos de un patrn de bits a otro.
La compresin lgica, por otro lado, se lleva a cabo por razonamiento lgico al sustituir esta
informacin por informacin equivalente.

38
3.8.4 Mtodos de compresin

En el caso de la compresin simtrica (Ilustracin 11), se utiliza el mismo mtodo para


comprimir y para descomprimir los datos. Por lo tanto, cada operacin requiere la misma
cantidad de trabajo. En general, se utiliza este tipo de compresin en la transmisin de datos.

ILUSTRACIN 11: COMPRESON SIMTRICA

La compresin asimtrica requiere ms trabajo para una de las dos operaciones. Es frecuente
buscar algoritmos para los cuales la compresin es ms lenta que la descompresin. Los
algoritmos que realizan la compresin de datos con ms rapidez que la descompresin 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 Compresin con perdida de datos

La comprensin con perdida es un mtodo de compresin de datos que permite comprimir datos que
al ser descomprimidos no son exactamente como los originales. Por lo general, la compresin con
prdida de datos se utiliza en la compresin de datos multimediales. Como este tipo de compresin
elimina informacin que est contenida en los datos que se van a comprimir, por lo general se habla
de mtodos de compresin irreversible (CCM, 2014).

Cuando se habla de imgenes, sonido y video, suele llamarse tambin compresin con prdida de
calidad, porque es la calidad lo que se est viendo afectada. La compresin con prdida de datos suele
lograr bastante mayor compresin que la compresin sin prdida. Esto significa que el resultado
ocupar menos bytes de almacenamiento. Por ejemplo, la compresin de audio puede llegar a
permitir que el archivo ocupe una dcima parte del original sin comprimir y prcticamente el odo
humano no capta la diferencia. Para las imgenes, tambin puede lograrse una alta tasa de compresin,
pero es ms evidente en el resultado final. En tanto en videos, la compresin con prdida puede lograr
que ocupe 1/300 parte del original (CCM, 2014).

39
Los mtodos de compresin con prdida 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 compresin. En tanto,
las imgenes JPG, logran una muy buena compresin, permitiendo seleccionar un nmero de
compresin del 0 al 100. El nmero ms alto permite mayor calidad, pero el archivo final ocupa ms
espacio. Una calidad aceptable es 80 (CCM, 2014).

3.8.6 Compresin sin perdida de datos

Tipo de algoritmos de compresin de datos que permite que la informacin original sea perfectamente
recuperada a partir de datos comprimidos. Cuando se comprimen imgenes, videos o sonidos sin
prdida, suele referirse como "compresin sin prdida de calidad". La compresin sin prdida de
datos, es utilizada para comprimir archivos o informacin 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 compresin sin prdida de datos pueden ser usados para comprimir
cualquier tipo de dato. Algunos tipos de datos no permitirn demasiada compresin (logrando que la
compresin sea similar en tamao en bytes que el archivo original) y otros lograrn una muy buena
compresin. Por lo general, los archivos de texto pueden ser muy comprimidos, en cambio archivos
de audio, no logran una significativa compresin (CCM, 2014).

3.8.7 Formato 7z

7z es un formato de archivo de alta relacin de compresin, es el formato por defecto del archivador
7-Zip.

Las principales caractersticas del formato 7z son:

Arquitectura abierta.
Alta relacin de compresin.
Fuerte cifrado AES-256.
Capacidad de utilizar cualquier compresin, conversin o mtodo de cifrado.
Apoyo a los archivos con tamaos de hasta 16.000.000.000 GB.
Nombres de archivo Unicode (7 Zip, 2012).
Compresin slida
Archivo de compresin de cabeceras

7z cuenta con una arquitectura abierta, por lo tanto puede soportar nuevos mtodos de compresin.
Los mtodos integrados actualmente son los mostrados en la siguiente tabla.

40
TABLA 3: METODOS DE COMPRESIN INTEGRADOS A 7Z

3.8.8 Algoritmo LZMA

LZMA es el mtodo por defecto y general de la compresin del formato 7z. Las caractersticas
principales del mtodo de LZMA:

Alto cociente de compresin.


Tamao variable del diccionario (hasta 4 GB).
Velocidad de compresin: cerca de 1 MB/s en la CPU de 2 GH.
Descompresin de velocidad: cerca de 10-20 MB/s en la CPU de 2 GH.
Pequeos requisitos de memoria para descomprimir (dependa de tamao del diccionario).
Pequeo tamao de cdigo para descomprimir: cerca de 5 KB.
Apoyo multi-threading y el hyper-threading de P4 (7 Zip, 2012).

El algoritmo de compresin de LZMA es muy conveniente para los usos encajados. LZMA se lanza
de conformidad con el GNU LGPL.

7-Zip tambin apoya la encripcin 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 funcin de la derivacin
basada en el algoritmo hash SHA-256. Una funcin de derivacin principal produce una llave
derivada de la contrasea del texto definida por el usuario. Para aumentar el coste de la bsqueda
exhaustiva para las contraseas 7-Zip utiliza el nmero grande de iteraciones para producir llave de
cifrado de contrasea del texto (7 Zip, 2012).

3.9 Apuestas en Repblica Dominicana


En Repblica Dominicana a finales de la dcada de los 80 se conoci el concepto de Bancas
Deportivas como una alternativa de entretenimiento y apuesta, que al mismo tiempo generaba
empleos de manera directa e indirectamente. Este concepto fue evolucionando, debido a que en sus

41
inicios los medios de tecnologa de informacin y control y comunicacin avanzada, creaba una
serie de prdidas financieras, que poco a poco fue mejorando. Todo este proceso cre las llamadas
bancas de apuestas, enlazadas a travs de la red de tecnologa de comunicacin que no slo se
concentran en apuestas deportivas, sino ofrecen servicios de Lotera, Pale, Juegos va satlite, entre
otros. Estos enlaces de Tecnologa de Informacin usan actualmente en poca
proporcin sistemas On-line con lneas dedicadas conectadas a servidores en muchas partes
de Estados Unidos de donde se obtiene la informacin de las jugadas as como
tambin datos estadsticos 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, comunicacin limitada a 1.2 Kbps, alta vulnerabilidad
del hardware, alta posibilidad de fraude y perdida en los Impuestos anuales del pas (Castillo, 2014).

En Repblica Dominicana existen variedad de loteras en cuanto a juegos de azar respecta, a


continuacin se conocer puntualmente cada una de las loteras y los juegos que ostentan, los cuales
sern parte vital del desarrollo que se lleva a cabo:

En Repblica Dominicana existen 4 Loteras, 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 Lotera Nacional: Esta es la principal, ya que pertenece al Gobierno de la Repblica Dominicana


y tan slo cuenta con un tipo de premio.

Lotera 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 inters, entre sus juegos estn: Loto Millonario, Quiniela
Pal, Loto ms, Sper Pal, Pega 3, Loto Pool, Sper Kinto TV y el Sper Bingo.

Lotera Loteka: Esta ha venido con fuerte competencia para Leidsa, ya que bsicamente es en esa
misma modalidad de premiaciones, entre los que se cuentan: Migra Tripleta Exacta, Mega Tripleta,
Mega Lneas, Mega Pal, Mega Quiniela, Mega Lotto.

Loto Real: Otra denominacin al igual que las dos anteriores y entre sus atractivos estn: Sper Loto,
Loto Real, Quiniela Real, Sper Pal Real, Pega Real.

A continuacin se encuentran los juegos que inicialmente se han contemplado para el desarrollo. Al
ser un desarrollo de mensajera dinmica, la inicializacin de este tipo juegos podr realizarse sin

42
inconveniente alguno, y provocar que tambin se puedan inicializar otro tipo de juegos indicando
cada uno de los parmetros de inicializacin requeridos en la mensajera.

Quiniela

En este tipo de juego se debe elegir un nmero del 1 al 100 y tiene tres oportunidades de ganar, se
juega inicialmente con 2 dgitos. Puede ganar con cualquiera de los tres nmeros 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) nmeros del 1 al 100 y tiene tres oportunidades de ganar, se
juega inicialmente con 4 dgitos (2 nmeros de 2 dgitos), se puede ganar combinando dos nmeros
cualquiera de los tres nmeros que resulten ganadores en el sorteo sin importar el orden en que se elija
los nmeros. 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) nmeros de 2 dgitos y tiene dos formas de ganar: Primero si acierta los tres
nmeros que resulten ganadores en el sorteo sin importar el orden que se hayan elegido, y tambin
acertando dos nmeros de los tres nmeros que resulten ganadores sin importar el orden de la
seleccin. 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

Sper Pale

Debe elegir el numero ganador del primer premio de por lo menos dos de las loteras que se ofrecen
(LOTEKA, LEIDSA, Lotera Nacional y Lotera Real). Se gana si acierta el primer premio de las
loteras escogidas, se juega con 4 dgitos al igual que el Pal (2 nmeros de 2 dgitos). Por cada
RD$1.00 apostado gana:

Por acertar el primer premio de ambas loteras: RD$3,000.00

43
El sper pale resulta ganador si los nmeros jugados resultan ganadores del premio mayor de cada
uno en una de las loteras de las combinadas.

Prez Abreu es, desde hace ms de 20 aos, uno de los principales proveedores en Repblica
Dominica de software para la administracin de bancas de apuestas. La empresa tena funcionando
una aplicacin para registrar apuestas de lotera bajo el esquema de trabajo online contra un servidor
que tena un grave inconveniente de seguridad. Debido a que en Repblica Dominicana las
conexiones de Internet no son muy consistentes, debieron incorporar un mecanismo por el cual, al
cortarse la comunicacin con el servidor se permitiera acumular apuestas localmente y, en el
momento de restaurarse la comunicacin, se enviaran estas apuestas al servidor (Sitepro, 2009).

La firma descubri que casualmente en algunas agencias se cortaba habitualmente la comunicacin


con el servidor unos 5 o 10 minutos antes de que empezaran los sorteos de la lotera local. Y luego se
recuperaba la conexin pocos minutos luego de que el sorteo haba comenzado. Dndose la fortuna
que, entre las jugadas que se haban realizado unos minutos antes de que empiece el sorteo, aparecan
apuestas a los primeros nmeros sorteados antes de recuperarse la conexin (Sitepro, 2009).

Francis Prez y Jorge Gutirrez, de Prez Abreu, explican: Descubrimos que algunos operadores
avivados desconectaban el cable de internet a propsito, antes de empezar el sorteo atrasaban el reloj
del equipo recaudador de apuestas, ingresaban apuestas con los nmeros favorecidos al principio del
sorteo, y luego volvan el reloj a la hora correcta, se conectaban a internet nuevamente y de esta forma
se transmitan las jugadas supuestamente acumuladas antes del inicio del sorteo y que no pudieron ser
enviadas por el corte de la conexin 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 Descripcin y definicin de la red a utilizar.

3.10.1 Definicin del mtodo de transmisin 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 comunicacin 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 informacin del archivo con un gasto mnimo de bytes usados por el
protocolo.

44
Posee un sistema de autenticacin de usuario con el que se proporcionan permisos a los
clientes
En su variacin a FTPS se logra proporcionar un nivel de seguridad ms alto a la informacin
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 informacin que ha sido interrumpida.

HTTP

Ventajas
El proceso de carga del archivo en el servidor es sencillo.
Es posible implementar algoritmos de reanudacin de descarga de informacin que han sido
interrumpidos
En su variacin a HTTPS se logra proporcionar un nivel de seguridad ms alto a la
informacin encriptada bajo el protocolo SSL.

Desventajas
El ancho de banda se desperdicia debido a la implementacin de formularios HTML.
La transferencia de informacin innecesaria provoca tiempos de ejecucin del sistema ms
elevados.
El gasto de datos es elevado debido a que el protocolo posee demasiadas etiquetas o bytes
innecesarios en la transmisin y la recepcin.

Es descartado el uso de HTTP para el sistema debido al incremento en el tiempo de ejecucin 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 transmisin de cada paquete.

3.11 Estado del arte

Teniendo en cuenta un estudio previo frente a desarrollos electrnicos enfocados plenamente en


las telecomunicaciones y entornos de programacin, se encontr algunos desarrollos a nivel
internacional y a nivel nacional, que se explican a continuacin:

45
3.11.1 Proyecto 1:

Domtica para Sistemas Embebidos Juan Manual Picerno, ken Tenzer, Universidad de la
Republica, Uruguay.
Se propuso una API que permite la programacin de aplicaciones con un alto grado de portabilidad.
La solucin propuesta est basada en una plataforma con arquitectura orientada a servicios
desarrollada en JAVA llamada OSGi. La API permite interactuar con distintas tecnologas de forma
homognea, los cuales incluso pueden estar distribuidos entre varios sistemas. Para mostrar su
aplicabilidad de desarrollo se trabaj un prototipo para la automatizacin de un bao en una
plataforma con recursos limitados, usando el proyecto USbAll que permite el control de dispositivos
genricos desde el punto de vista USB. Para interactuar con distintas tecnologas tambin se prob el
sistema con dispositivos controlados por radiofrecuencia. Se sobre escribi el firmware original del
router Azuzwl500w con OpenWrt una distribucin 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 tecnologas de distribucin 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 Tecnolgica de la Mixteca, Mxico) Diciembre de 2009.

El proyecto establece una comunicacin entre un sistema embebido y un centro de informacin.


El intercambio de informacin 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 informacin con el
MT100SEM. El MUC es el encargado de configurar y controlar los dispositivos perifricos.
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 anlogas y mostrar informacin de cualquier sistema.
Todo realizado en la Universidad Tecnolgica de Mixteca aprovechando su red de comunicacin tipo
Ethernet, para un sistema de vigilancia (Universidad tecnologica de Mixteca, 2009).

46
3.11.3 Proyecto 3:
Pago electrnico a travs de telfonos mviles

En vista de la evolucin de las comunicaciones surgi la idea de crear un sistema de pago a travs del
telfono mvil, el cual solicita la autorizacin para realizar el cobro a la tarjeta de crdito, mediante
un software instalado en el telfono mvil.

El objetivo es ofrecer un mecanismo de pago electrnico a las empresas y personas desde cualquier
lugar geogrfico con cobertura celular y as extender el uso de la infraestructura de pagos electrnicos
en los negocios de gran y menor tamao (PYMES), tales como: comercio al menudeo, tiendas de
abarrotes, locales de comida, islas, papeleras, farmacias y hasta taxis (Espinosa Peeherrera & Soto
Arango, 2009).

3.11.4 Proyecto 4:

Instalacin de Linux para ARM en sistemas empotrados (Universidad de Granada, Espaa,


2009).

Este proyecto cubre lo necesario para instalar Linux en una placa de desarrollo con procesador ARM
como la Beagle Board. Describe tambin un mtodo para generar software ejecutable por la placa. Se
mostrara una forma sencilla de construir el sistema utilizando el emulador Qemu en la mquina de
escritorio de forma que se tenga el sistema bsico funcionando rpidamente y sin complicaciones.
El mtodo que se utiliz para instalar Linux y las dems 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 mtodos 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 hara en un PC.
El segundo realiza la instalacin en una mquina virtual en un PC. La instalacin es similar a la que se
hara en un PC de forma nativa, pero en este caso se instalara en la tarjeta SD. Una vez hecha la
instalacin y configuracin ya podemos arrancar la placa con la tarjeta introducida y acceder a ella
desde el PC a travs del puerto serie.
Este proyecto muestra de manera minuciosa como instalar Linux en un sistema embebido lo cual es
muy interesante y provechoso. Por ser libre, muestra con respecto a nuestro proyecto la versatilidad
de estos sistemas para diferentes aplicaciones (Navarro R. C., 2010).

47
3.11.5 Proyecto 5:

Modulo didctico de instrumentacin electrnica implementado con tecnologa FPAA


(Universidad Distrital Francisco Jos de Caldas, Facultad Tecnolgica)

Es un proyecto de desarrollo ya que la finalidad del mismo es el aprovechamiento de nuevas


tecnologas en la instrumentacin electrnica, 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 aplicacin que
hay en nuestro contexto educativo, este proyecto explora ms a fondo esta tecnologa, que puede ser
de gran utilidad en el diseo de sistemas de instrumentacin electrnica en el grupo de investigacin
INTEGRA y como consecuencia, permitir la reduccin de materiales a utilizar, costos en el
proceso, y tiempo de ejecucin de un diseo (Cuevas, 2007).

3.11.6 Proyecto 6:

Propuesta de un plan para adquirir una solucin tecnolgica que permita la administracin y
monitoreo de la red de cajeros automticos del banco popular y de desarrollo comunal

El Banco Popular y de Desarrollo Comunal, en su afn por sobresalir en el mercado financiero


costarricense y brindar ms y mejores servicios a sus clientes, se encuentra en un proceso de
modernizacin de su plataforma tecnolgica, incluyendo la red de cajeros automticos.

Dado lo anterior, se estableci como objetivo principal en esta investigacin, proponer un plan para
adquirir una solucin tecnolgica que permita la administracin y monitoreo de la red de cajeros
automticos del Banco Popular y de Desarrollo Comunal (Arias Guerrero, 2009).

4. DISEO DE PROTOCOLO DE COMUNICACIN Y DESARROLLO DE LGICA


SOBRE SISTEMA EMBEBIDO

Inicialmente el proyecto se ha diseado con transacciones bsicas, las cuales corresponden a la


columna vertebral del software y obedecen a la lgica 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 aplicacin). El primer protocolo consiste en el diseo de mensajera
personalizada por parte del servidor de Prez Abreu S.A, ubicado en Repblica 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 programacin que se ha utilizado en este caso ha sido Programacin estructurada, la cual
est compuesta por un conjunto de tcnicas que han ido evolucionando y aumentando
considerablemente la productividad del programa reduciendo el tiempo de depuracin y

48
mantenimiento del mismo.

Esta programacin estructurada utiliza un nmero limitado de estructuras de control, reduciendo as


considerablemente los errores (Alvarez, 2006).

Esta tcnica incorpora:

Diseo descendente: El problema se descompone en etapas o estructuras jerrquicas.


Recursividad abstracta: Consiste en descomponer las acciones complejas en otras ms simples
capaces de ser resueltas con mayor facilidad.
Estructuras bsicas: Existen tres tipos de estructuras bsicas:
o Estructuras secunciales: En donde cada accin sigue a otra accin secuencialmente. La salida de
una accin es la entrada de otra.
o Estructuras selectivas: En estas estructuras se evalan las condiciones y en funcin del resultado de
las mismas se realizan unas acciones u otras. Se utilizan expresiones lgicas.
o Estructuras repetitivas: son secuencias de instrucciones que se repiten un nmero determinado de
veces.

Las principales ventajas de la programacin estructurada son:


Los programas son ms fciles de entender
Se reduce la complejidad de las pruebas
Aumenta la productividad del programador
Los programas quedan mejor documentados internamente.

Debido a lo anteriormente sealado, se ha elegido este tipo de programacin y ha facilitado


notablemente el desarrollo de cada uno de los mdulos que componen el aplicativo, y adems se ha
separado con eficiencia la capa de mensajera de interfaz grfica, as como el modulo que maneja la
memoria del dispositivo

4.1 TCP IP

La comunicacin mediante el protocolo TCP/IP se realiza a travs de la red Ethernet de intranet o


internet que posea la infraestructura del sitio donde se ubique el datafono.

Es el mtodo de comunicacin ms rpido y efectivo que se utiliza en los datafonos, esto debido a que
el medio de trasmisin no es compartido y puede ser utilizado todo el ancho de banda del mismo para
el establecimiento de la comunicacin y la transferencia de informacin.

49
Ventajas
El protocolo a implementar se define entre el cliente y el servidor, con esto se aprovecha al
mximo el ancho de banda.
La implementacin de protocolo SSL brinda un nivel de encripcin de datos ptimo.
La reanudacin de descargas interrumpidas es definida entre cliente y servidor.

Desventajas
La definicin de protocolo y funcionalidad completa implica un desarrollo estructural
avanzado que contemple todos los escenarios presentes en un sistema de comunicacin.

La idea es utilizar este protocolo ya que posee un nivel de seguridad confiable con adiciones de
protocolos criptogrficos sobre el mismo, adems de ser un protocolo orientado a conexin, lo cual
indica que se implementara con conexin por demanda y sacara el mximo provecho del sistema
GPRS.

En la ilustracin 12 se observa un esquema simple de la comunicacin que se lleva a cabo en este


punto.

ILUSTRACIN 12: ESQUEMA TCP

4.2 GPRS

Es necesario seguir una serie de pasos en el datafono para configurar la conexin GPRS, una vez se
configura el modem GPRS del datafono con los parmetros correspondientes al proveedor de
servicios, se establece la comunicacin entre el datafono y el operador de telefona. Esta
comunicacin se realiza mediante protocolo PPP; Sin embargo, la comunicacin entre el operador de
telefona y el servidor externo se realizara mediante protocolo TCP/IP.

50
Para transmitir datos mediante GPRS se deben tener en cuenta los parmetros de comunicacin del
servidor externo, estos parmetros son:

a. Direccin Lgica (IP).


b. Puerto TCP de escucha.

La conexin del datafono hasta el servidor externo presenta los siguientes pasos que deben
desarrollarse al momento de enviar datos a travs de la red:

1. Establecimiento de la conexin PPP.


2. Autenticacin con el proveedor de telefona y datos de navegacin mvil.
3. Apertura del socket de comunicacin TCP.
4. Envo de datos en PPP.
5. Liberacin de recursos lgicos y fsicos del proceso de comunicacin TCP.
6. Liberacin de los recursos utilizados por la conexin PPP.

Los parmetros de configuracin del datafono son los siguientes:


FRECUENCIA MODEM
Modem 850/1900

Desea cambiar de bandas?

SI = ENTER NO = CLR Cambio de banda dependiendo del operador

ILUSTRACIN 13: CONFIGURACON BANDAS

El APN (Access Point Name) se configure de manera manual o se elige alguno por defecto
dependiendo el operador. Igualmente se establece usuario y contrasea si posee.

ILUSTRACIN 14: CONFIGURACIN APN.

51
APN

IKKLKL
Nuevo Valor:

Especificacin APN manualmente


ILUSTRACIN 15: INGRESAR APN

User:

IKKLKL
Nuevo Valor:

Usuario APN
ILUSTRACIN 16: INGRESAR USUARIO SIN APN

Contrasea APN
ILUSTRACIN 17: INGRESAR CONTRASEA

La Ilustracin 18 describe el proceso de negociacin y autenticacin del Terminal punto de venta


frente a la red de telefona mvil para el acceso a la transferencia PPP.

52
ILUSTRACIN 18: DIAGRAMA DE FLUJO CONEXIN GPRS

4.3 Diagrama de flujo del desarrollo completo (Con protocolo de comunicacin implcito)
Ilustracin 19 siguiente pgina.

53
54
ILUSTRACIN 19: DIAGRAMA DE FLUJO PRINCIPAL
4.4 Diagrama de clases bsicas del desarrollo

ILUSTRACIN 20: DIAGRAMA DE CLASES

4.5 Diagrama de casos de uso

En el siguiente diagrama se encuentra la descripcin escrita del comportamiento del sistema al


afrontar cada una de las tareas que demanda este tipo de negocio. Esta descripcin nos muestra 5
actores, el autorizador, el operario de la mquina (Sistema embebido), la banca de apuestas, que es la
central que registra por puntos del territorio las mquinas, el cliente, el cual consume el producto que
se comercializa con la mquina y el C.S.I o servicio de informacin del cliente, del cual depende la
descarga remota de nuevas versiones del aplicativo generado.

55
ILUSTRACIN 21: CASOS DE USO

56
4.6 Transacciones implementadas

A continuacin se presentan las transacciones dispuestas y anteriormente mencionadas, las cuales se


encuentran embebidas en las tecnologas y protocolos anteriormente descritos (TCP/IP y GRPS).

Para las siguientes transacciones se tendrn en cuenta las siguientes identificaciones de brindaran
mayor claridad al momento de explicar la construccin de una transaccin:

ID Transaccin > 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-Inicializacin
En ningn 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 ms ampliamente explicado en
transacciones posteriores.
En primera instancia se contempla una inicializacin con la mquina totalmente vaca,
posteriormente se contemplara una actualizacin de productos con una mquina previamente
inicializada.

Login online

Usuario:
IKKLKL
Clave:

ILUSTRACIN 22: LOGIN

TX:
09
|
2a000206
|
0-1 Estado de inicializacin: 0 no est inicializado, 1 ya ha inicializado el pos

57
|
1243 Usuario (4 bytes en ASCII)
|
1234 Clave (4 bytes en ASCII)
|
1234 Checksum (4 bytes en ASCII)

El usuario y la clave componen el Login del aplicativo, lo que quiere decir que son las credenciales de
ingreso que mantendr la mquina 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 peticin o envo.
Respuesta a una solicitud errada:
RX:
09
|
1-2 transaccin errnea (1 byte)
| Separador
02 cantidad errores (2 bytes)
@
01 lnea de error (2 bytes)-cuando es genrico va en ceros-(inicia en uno)
|
Cadena de texto que describe el error.

Ejemplo:
09|1|01@00|error en checksum
09|2|02@01|msj1@03|msj2

Respuesta a una solicitud exitosa:

58
RX:
09
|
0 El cero indica que la respuesta fue exitosa, que no hay errores en el envo.
|
201112271300 Fecha y hora para sincronizacin del POS (14 bytes)
|
S Este parmetro indica si el aplicativo funcionar offline, S=Si.
@
<o> Carcter que indica inicializacin (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 carcter que sigue a la @
Si es:
< Este carcter indica que no viene inicializacin.
> Con este carcter se indica que a continuacin viene inicializacin completa.
Seguido a ese carcter se enva 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 ms 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 lotera 1 BCD
Nombre lotera 20 ASCII
abreviatura 4 ASCII

59
Fecha-hora sorteo 14 ASCII
Tipo venta 2 ASCII
Juegos disponibles 30(variable) BCD
TABLA 4: CABECERA DE VENTAS

Nota: Esta tabla relaciona tanto loteras como operadores de recarga cuando sea un servicio de
recarga solo puede venir un juego habilitado.
Ejemplo con la inicializacin de una lotera:
01 >Id tabla
00 45 >Longitud del registro
01 >Numero de Registro de la tabla
01 > Id Lotera
4e 41 43 2e 20 54 41 52 44 45 20 20 20 20 20 20 20 20 20 20 > Nombre Lotera
4c 4f 4e 54 > Abreviatura Lotera
32 30 31 35 30 37 32 31 31 33 35 34 30 30 > Fecha Sorteo
30 31 > Tipo de venta (01 Lotera, 02 Recargas)
01 02 03 15 > Juegos habilitados por ID

Despus de inicializar cada una de las loteras, 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(mximo para ASCII
impresin-pantalla)
Longitud de apuesta 1 BCD
Prioridad juegos 1 BCD
Buscar Lotera 1 BCD
Monto Mnimo 3 ASCII
Monto Mximo 7 ASCII
Limite Numero 7 ASCII
TABLA 5: TABLA DE JUEGOS

60
Ejemplo con la inicializacin de los juegos:
02 > Id tabla
00 27 > Longitud del registro
01 > Nmero de registro de la tabla
01 > Id Juego
51 55 49 4e 4e > Nombre Juego
02 > Longitud Apuesta o cantidad de nmeros necesarios para activar el juego
01 > Prioridad del juego, el juego puede ser de prioridad 2 y jugarse con 2 loteras a la vez.
01 > Buscar Lotera, el cual se utiliza para poder elegir el tipo de lotera cuando la prioridad es 2.
30 30 31 > Monto mnimo para el juego.
30 30 30 30 35 30 30 > Monto mximo para el juego.
30 30 31 30 30 30 30 > Limite nmero, o cantidad de veces que se puede jugar el juego diario.

Nota:
1. Se adicionan campos de longitud para asignar dinmicamente el juego con su respectiva
longitud.
Se asigna id de prioridad para los juegos con el mismo nmero de longitud, nunca se va a repetir la
prioridad ms 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 direccin
De 03 en adelante es el pie de pgina del ticket

61
Ejemplo con la inicializacin 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 direccin de la banca de apuestas
03 > Id Tabla
00 18 > Longitud de los datos de la tabla
03 > Registro de pie de pgina del tiquete
54 65 6c 20 3a 20 38 30 39 2d 30 30 30 2d 30 30 30 31 >Texto de pie de pgina
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 loteras y el id 02 a recargas, a medida que se adicionen
productos se agregaran los id fijos de 03 en adelante.
Ejemplo con la inicializacin de los tipos de producto:
04 > Id Tabla
00 21 > Longitud datos
01 > Nmero 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 > Nmero del registro de la tabla.
52 45 43 41 52 47 41 53 20 20 20 20 20 20 20 20 20 20 20 30 32 > Nombre producto

62
04 > Id tabla
00 21 > Longitud datos
03 > Nmero 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 cdigo
sea mucho ms sencillo y eficiente debido a que se utiliza la porcin de memoria necesaria porque se
envan las longitudes de los registros. Si en momento determinado se necesitan implementar ms
tablas, debido a esta dinmica se har muy sencillo por que a nivel de cdigo dise con la lgica ms
bsica en la cual se seala cada tabla por casos o 'case'.

ILUSTRACIN 23: MENU PRINCIPAL

Las siguientes transacciones han sido construidas con una mensajera completamente en
formato ASCII, ya que para el servidor es mucho ms sencillo interpretar mensajera en dicho
formato, aunque este tipo de mensajera consuma un mayor nmero de datos, la interpretacin
por parte del servidor est garantizada al ser formato ASCII.

4.6.2 Transaccin de venta

Antes de explicar este mdulo, se debe mencionar que este desarrollo cuenta con un sistema de venta
offline, el cual entra en funcionamiento cuando la conexin a la red es problemtica.
Este tipo de problemas son muy frecuentes en Repblica Dominicana debido a la fragilidad en la
infraestructura de comunicaciones mviles en dicho pas.
Este sistema es capaz de vender fuera lnea y generar un lote completo de ventas para sincronizar con
el servidor. Aunque este tipo de procedimiento no es muy confiable, se ha diseado una lgica que no
permite de ninguna manera perder las ventas que se han hecho offline desde el POS.

63
A pedido del cliente se ha solicitado que mximo se guarden 4 das de transacciones sin sincronizar,
ya que de all en adelante es un tiempo exagerado debido a la lgica que manejan los juegos de azar en
sus sorteos.
Como consecuencia a este mdulo de venta offline existe un mdulo de sincronizacin que enva
estas apuestas al servidor el cual ser explicado ms adelante.

ILUSTRACIN 24: MODO OFFLINE

Es necesario tener en cuenta que la estructura de la venta es la misma para offline y online. Solo va a
cambiar el Id de transaccin, de igual manera suceder con la venta de recargas.
Se debe imprimir la lotera en el tiquete de venta tener y se debe tener en cuenta el tema del sper pale
puesto que es un nmero de 4 dgitos que juega con 2 loteras a la vez (interfaz especial para
seleccionar la lotera con la cual se conjuga el nmero del sper pale).
Esta trama contiene la siguiente cabecera:
Campo Longitud

Id transaccin 2 Bytes

STAN(Consecutivo transaccin) 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)

Cdigo generado por el POS 7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Cdigo de cliente frecuente 5 Bytes

Separador de fin de cabecera 1 Byte @

TABLA 8: CABECERA DE LA VENTA

64
Ejemplo cabecera TX:
00|000003|003|3C039714|00008954871223654878|000013300|20150723171258|0000000|00000@
Despus del separador de '@' se enva el detalle de cada venta:

Campo Longitud

Id del juego 2 Bytes

Id de lotera 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 ms 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

ILUSTRACIN 25: GRILLA

65
Existen 2 tipos de recepcin, exitosa y declinada. En el caso de recepcin declinada:

00 id transaccin (2 bytes en ASCII)


01 id transaccin (2 bytes en ASCII)
| Separador
1 Cdigo de respuesta con error
| Separador
02 cantidad errores (2 bytes)
@ Separador
01 lnea de error (2 bytes)-cuando es genrico 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 algn
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 Transaccin 2 Bytes
Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)
STAN(Consecutivo de la transaccin) 6 Bytes
Cdigo de Autorizacin 10 Bytes ( Impreso en Cdigo de barras)
Nmero 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 recepcin exitosa RX:


00|0|000001|1234567890|1234567|20111228120000|20111228

66
ILUSTRACIN 26: VENTA APUESTA

ILUSTRACIN 27: TIQUETE DE VENTA

4.6.3 Transaccin de reversin


La reversin se ejecuta siempre y cuando el aplicativo sea 100% ONLINE, en ningn caso existirn
las reversiones fuera de lnea. Un reverso se presenta a nivel financiero cuando no se recibe
respuesta alguna en la solicitud de una venta, lo que indica que es probable que el servidor no haya

67
recibido el envo de lo transaccin o que existi algn problema de red tanto en el envo como en la
respuesta.
Se enva id de transaccin 02 y la trama se enva 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 envo exitoso RX:
02 Id transaccin (2 bytes en ASCII)
| Separador
0 Cdigo de respuesta (1 Byte)

ILUSTRACIN 28: REVERSO EXITOSO

4.6.4 Transaccin de anulacin


La transaccin de anulacin 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 transaccin no se
puede anular.
El Id de la transaccin es un 03, este tipo de transaccin solo est disponible desde el POS que
imprimi la venta, de lo contrario es rechazada por el servidor.
La anulacin se hace digitando el nmero de verificacin del ticket, se compara en el pos y luego se
solicita la informacin del cdigo de referencia para evitar fraudes.

68
ILUSTRACIN 29: CAMPO DE ANULACIN

El siguiente es el esquema de envo en la anulacin TX:


Campo Longitud

Id transaccin 2 Bytes

Serial Terminal 8 Bytes

Usuario 4 Bytes

Referencia del tiquete a anular 7 Bytes

STAN( Consecutivo de venta ) 6 Bytes

Tipo de anulacin (1 OFFLINE, 0 ONLINE) 1 Byte

Total de offline ( Por si el tiquete fue sincronizado) 12 Bytes

Fecha y hora de anulacin 14 Bytes

TABLA 11: ENVO DE ANULACIN

Captura de anulacin TX:


03|3C039714|4321|1300530|000004|0|000000000000|20150724125809
Tipo anulacin:
0 ONLINE
1 OFFLINE
Respuesta Exitosa de una anulacin RX:
Campo Longitud

Id Transaccin 2 Bytes

Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)

Total del tiquete anulado 9 Bytes

Fecha y hora de anulacin 14 Bytes

TABLA 12: RESPUESTA DE ANULACIN

69
Ejemplo RX:
03|0 | 001000000 |20111228120000

4.6.5 Transaccin de Batch Upload


En trminos 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 tambin si en el cierre de sesin, la cantidad de ventas difiere como
consecuencia de las ventas offline, en este caso se sugiere al POS realizar sincronizacin manual
la cual ser explicada posteriormente a nivel transaccional.

Transaccin de envo TX:


Se enva id de transaccin 05 y tiene el mismo formato de una transaccin de venta.
La respuesta de error es exactamente igual a la venta en su formato.

Respuesta exitosa RX:


05 Id transaccin (2 bytes en ASCII)
|
0 Cdigo de Respuesta (1 byte)

4.6.6 Transaccin de lista de nmeros

Es una transaccin bastante especfica y muy importante, ya que nos detalla los registros de cada
lotera, incluyendo dinero y nmeros de cada transaccin. Particularmente esta transaccin adems
de retornar los registros especficos de cada lotera, permite tambin la impresin de los nmeros
que se han jugado con dichas loteras en la parte posterior de estos datos, estos datos son impresos y
tomados desde la mquina. Despus de la respuesta de la transaccin se comparan los resultados
respondidos por el servidor y los computados por la mquina, de existir alguna diferencia se debe
enviar un Batch.

70
ILUSTRACIN 30: MENU CONSULTAS

Formato de envi de la transaccin:


Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Fecha inicial del reporte 14 Bytes

Fecha final del reporte 14 Bytes

TABLA 13: ENVO DE BATCH

Captura de envi de la transaccin TX:


14|3C039714|4321 |20150724000000|20150724235959

Formato de respuesta Cabecera:


Campo Longitud
Id Transaccin 2 Bytes
Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de loteras 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 NMEROS

71
Captura de respuesta exitosa de la transaccin RX cabecera:
14|0 |001|00000005600|00000000000|000000000000|000000005600

Posterior a la cabecera se enva el detalle de la transaccin, es decir la informacin por lotera


separado por un @ el cual separa el detalle de la transaccin, y vara dependiendo de la cantidad de
loteras que se presenten en el reporte, cada lotera va separada con un @.

Formato del detalle de la transaccin:


Campo Longitud

Id Lotera 2 Bytes

Nmeros 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 lotera 12 Bytes


TABLA 15: DETALLE DE RESPUESTA LISTA NMEROS

Captura de respuesta exitosa RX:


01 | ****** |000000005600|000000000000|000000000000|000000005600

ILUSTRACIN 31: PARAMETROS DE CONSULTAS

72
ILUSTRACIN 32: TIQUETE DE LISTA DE NMEROS

La respuesta errnea tiene el mismo formato de las transacciones anteriores, solo cambia el id de la
transaccin.

4.6.7 Transaccin de consulta de ventas


Lo ms importante en este tipo de transaccin antes de realizar la recepcin es tener en cuenta el
rango de fechas en el cual se va a realizar la consulta. Esta transaccin especialmente debe tener
fecha inicial de consulta y fecha final de consulta. Se debe enviar un total de ventas online y offline
por separado.

73
En la consulta debe enviar el total offline con el fin de saber si es necesario sincronizar, as mismo
se va a verificar que los totales online entre el servidor y el POS coincidan. En la respuesta del
servidor el campo de diferencia es la cantidad de dinero que le falta al POS por sincronizar,
generalmente antes de que viaje esta transaccin, se realiza una consulta de lista nmeros, lo cual es
solicitado por el servidor para obtener un resultado ms exacto del reporte.

Este reporte es muy general y se debe imprimir en pantalla y en papel.


Formato del envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 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: ENVO DE CONSULTA

Captura del envo 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 nmero que llega al id de transaccin: Si en el cdigo de
respuesta llega en , el aplicativo procede a realizar un Batch, ya que habra diferencia entre los
montos de POS y el servidor, de tratarse del nmero 2, se seguira la lgica de las transacciones
anteriores.
Formato de respuesta exitosa RX:
Campo Longitud

Id transaccin 2 Bytes

Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)

Total en ventas 12 bytes (con 2 decimales a la derecha)

Total de juegos 2 Bytes

74
Separador de juegos 1 Byte @ Indica de los datos de un juego

Id de juego 2 Bytes

Id de lotera 9 Bytes

Total de venta del juego 12 Bytes ( Con 2 decimales a la derecha)

Separador 1 Byte @ Indica finalizacin 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

ILUSTRACIN 33: PARAMETROS DE REPORTE

ILUSTRACIN 34: TIQUETE CONSULTA GENERAL

75
4.6.8 Transaccin de pagos
En este mdulo se solicita al operador del POS el STAN del ticket y el serial de la mquina donde
se vendi el ticket:
Formato del envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Referencia del tiquete 7 Bytes

STAN (Consecutivo tiquete) 6 Bytes

Serial Mquina que hizo la venta 8 Bytes

TABLA 18: ENVO DE PAGOS

Envo del POS TX:


07|2a000203|1234|1234567|123456|2a000123

Recepcin exitosa RX:


Campo Longitud
Id Transaccin 2 Bytes
Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)
Hora y fecha del pago 14 Bytes
Nmero de verificacin 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 impresin de un tiquete certificando el pago.
La respuesta de error es igual a la respuesta de la venta.

76
4.6.9 Transaccin de consulta de tiquetes
Este mdulo se ejecuta antes de realizar el pago del tiquete, se pueden hacer consultas desde
cualquier terminal, si el tiquete era ganador se ingresa al mdulo de pago de tiquete.

ILUSTRACIN 35: CONSULTA DE TIQUETES

Formato del envo TX:


Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Nmero de tiquete 7 Bytes

Referencia del tiquete 10 Bytes

TABLA 20: ENVO CONSULTA TIQUETES

Captura de Envo POS TX:


08|2a001234 |1234|1234567|2333336666

Captura de respuesta exitosa (RX):


08 Id transaccin
|
0 Cdigo de respuesta exitoso
|
123456700 Premio (9 bytes) dos decimales, nunca puede ser cero el total del premio.

La recepcin en error es similar a las dems transacciones, solo cambia el Id.

77
4.6.10 Transaccin de cierre de ventas
En la transaccin de cierre lo ms importante es enviar las fechas de inicio del login y del momento
en que se enva la misma transaccin, es decir la fecha final. Nuevamente al igual que en las
consultas se enva el total online y el total offline de todas las ventas realizadas para realizar una
posterior sincronizacin 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 envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Fecha en la cual se hizo inicializacin 14 Bytes

Fecha actual 14 Bytes

Total de ventas ONLINE 9 Bytes

Total de ventas OFFLINE 9 Bytes

TABLA 21: ENVO DE CIERRE

Captura de envo de la transaccin TX:


10|2a012345 |1234|20111229080000|20111230040500|002000000|000100000
Formato de respuesta exitosa RX:
Campo Longitud

Id transaccin 2 Bytes

Cdigo 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 lotera 9 Bytes

Total de venta del juego 12 Bytes ( Con 2 decimales a la derecha)

Separador 1 Byte @ Indica que viene el total entre OFFLINE Y


Sincronizado
Total entre OFFLINE y Sincronizado 12 Bytes
TABLA 22: RESPUESTA DEL CIERRE

78
Captura de respuesta Exitosa RX:
10|0|000000007900|02@02|01|000000005600@04|03|000000002300@000100000000
En este tipo de transaccin el error puede apuntar a un Batch si los totales no coinciden
En otro caso el formato de respuesta con solicitud errnea ser la misma de las anteriores
transacciones.

ILUSTRACIN 36: PANTALLA DE CIERRE

4.6.11 Transaccin 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 loteras para ser mucho ms preciso.

ELIJA LOTERIA
1. NAC. TARDE
2. NAC. NOCHE
3. LEID. NOCHE
IKKLKL
4. REAL TARDE
5. LTKA TARDE

ILUSTRACIN 37: SELECCIONAR LOTERIA EN REPORTE PARCIAL

Formato del envo TX:


Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Fecha en la cual se hizo inicializacin 14 Bytes

79
Fecha final del reporte 14 Bytes

Id de lotera a consultar 2 Bytes

TABLA 23: REPORTE PARCIAL ENVO

Captura del envo TX:


11|3C039714|4321|20150724000000|20150724235959|01
Formato de respuesta exitosa RX:
Campo Longitud

Id transaccin 2 Bytes

Cdigo 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 lotera 4 Bytes

Diferencia entre ventas y pagos 12 Bytes

Titulo de la lotera consultada 31 Bytes, se justifica con espacios a la derecha

Nombre de la banca que distribuye la lotera 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.

ILUSTRACIN 38: TIQUETE DE REPORTE PARCIAL

80
4.6.12 Transaccin de consulta de tiquetes ganadores
La consulta de tiquetes ganadores responde en una sola transaccin la cantidad de tiquetes
ganadores por lotera 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 envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 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 transaccin:
Formato de respuesta cabecera RX:
Campo Longitud

Id transaccin 2 Bytes

Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)

Cantidad de loteras 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 despus 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:


Despus de la cantidad de tiquetes ganadores se separa con un @ las loteras que vienen en la
respuesta de la transaccin, la cantidad de @ indica la cantidad de loteras, y posterior a ello viene
este formato de envo, el cual se repite segn la cantidad de loteras:

81
Campo Longitud

Id Lotera 2 Bytes

Pagos en nmeros 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 nmeros ganadores 3 Bytes

TABLA 27: DETALLE DE RESPUESTA TIQUETES GANADORES

Si en la cantidad de nmeros ganadores existe un valor mayor a cero se debe imprimir en el tiquete
la data con los nmeros ganadores y el detalle que conlleva cada nmero ganador, la cantidad de
bytes mxima por lotera para nmeros ganadores y detalles de cada nmero esta en 32 bytes, de
pasar este lmite 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

ILUSTRACIN 39: REPORTE DE TIQUETES GANADORES

82
4.6.13 Transaccin 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 loteras relacionadas con las fechas que se envan en la previa solicitud.
Formato del envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Fecha inicial de la consulta 14 Bytes

Fecha final del reporte 14 Bytes

TABLA 28: ENVO DE CIERRE POR FECHA

Captura del envo TX:


13 |3C039714 |4321 |20150724000000 |20150724235959
Formato de respuesta RX:
Campo Longitud

Id transaccin 2 Bytes

Cdigo 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 prdida 12 Bytes ( Con 2 decimales a la derecha)

Total Recibido 12 Bytes ( Con 2 decimales a la derecha)

Separador (Separa los reportes por fechas) 1 Byte @

Fecha del reporte especifica 8 Bytes

Total venta una fecha 12 Bytes ( Con 2 decimales a la derecha)

Total pagos una fecha 12 Bytes ( Con 2 decimales a la derecha)

TABLA 29: RESPUESTA DE CIERRE POR FECHA

83
Captura de respuesta de una transaccin 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.

ILUSTRACIN 40: REPORTE DE CIERRE POR FECHA

4.6.14 Transaccin de sincronizacin

Este tipo de transaccin es clave en todo el desarrollo, ya que permite la interactividad entre el
modulo offline y el servidor, por medio de esta transaccin 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 transaccin son los mismo de la transaccin de ventas, lo nico que
cambia es el id de la transaccin, la cual se marca con un 01 cuando es offline, lo cual indica que los
datos son de una sincronizacin. Todos los datos viajan en formato ASCII al igual que en la mayora
de las transacciones.

84
Formato de envo cabecera TX:
Campo Longitud

Id transaccin 2 Bytes

STAN(Consecutivo transaccin) 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)

Cdigo generado por el POS 7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Cdigo de cliente frecuente 5 Bytes

Separador de fin de cabecera 1 Byte @

TABLA 30: ENVO DE SINCRONIZACIN

Formato de envo detalle de la transaccin TX:


Despus del separador de '@' se enva el detalle de cada venta:
Campo Longitud

Id del juego 2 Bytes

Id de lotera 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 ENVO EN SINCRONIZACIN

En caso de existir ms de un juego en el detalle, estos se separan por @, el ltimo juego no termina
con @.

Captura de Envo TX:


01|000009|001|3C039714|88994994900303042049|000002300|20150724163040|0975202|00000
@04 |03|0002300|12

85
Formato de respuesta exitosa RX:
Campo Longitud

Id Transaccin 2 Bytes

Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)

STAN(Consecutivo de la transaccin) 6 Bytes

Cdigo de Autorizacin 10 Bytes ( Impreso en Cdigo de barras)

Nmero 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 SINCRONIZACIN

Captura de respuesta exitosa RX:


01|0|000004|9507704045|0349679|20150729182944|20150729

El error en respuesta maneja el mismo formato de las anteriores transacciones.

ILUSTRACIN 41: PANTALLA DE SINCRONIZACIN

Es importante saber que en este tipo de transaccin la nica que recibe respuesta es la primera
solicitud, lo que indica que al existir ms de 1 transaccin offline por sincronizar, solo se hace el
envo y el servidor no responder, debido al tiempo que se toma una sola transaccin 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 Repblica Dominicana.
Con respecto a lo anterior se ha desarrollado una sola transaccin que recibe el nombre de consulta
de sincronizacin y su formato es el siguiente:

86
Formato de envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Fecha de las ventas a consultar 8 Bytes

Cantidad de transacciones a consultar 4 Bytes

Nmero de tiquete a consultar 7 Bytes

TABLA 33: ENVO CONSULTA SINCRONIZACIN

El ultimo parmetro de esta transaccin se multiplica dependiendo de la cantidad de


transacciones a consultar, e igualmente se separan estos nmeros por un |.

Captura de envo TX:


17|3C039714|20150729|0004|0349679|1565655|0349679|1565655
Formato de respuesta RX:
Campo Longitud
Id Transaccin 2 Bytes
Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)
Cantidad de transacciones consultadas 4 Bytes

Indica si la transaccin fue sincronizada 1 Byte (N no, S s)


TABLA 34: RESPUESTA CONSULTA SINCRONIZACION

Captura de respuesta RX:


17|0|0004|SSSS

4.6.15 Transaccin de Informe al final del sorteo

El informe al final del sorteo tambin se realiza por loteras, nos retorna cada uno de los valores del
sorteo e indica especficamente los dineros que han sido debitados por tem teniendo en cuenta
cantidad de ganadores.

87
Formato del envo TX:
Campo Longitud

Id transaccin 2 Bytes

Serial Mquina 8 Bytes

Usuario 4 Bytes

Fecha inicial de la consulta 14 Bytes

Fecha final del reporte 14 Bytes

Id lotera a consultar 2 Bytes

TABLA 35: INFORME AL FINAL DEL SORTEO TX

Captura de envo TX:


12|3C039714|4321|20150724000000|20150724235959|01

Formato de respuesta RX:


Campo Longitud

Id transaccin 2 Bytes

Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)

Nombre de la banca Variable con un mximo de 31 Bytes

Fecha del reporte 14 Bytes

Nombre de la lotera del sorteo Variable con un mximo de 31 Bytes

Nmeros ganadores Variable con un mximo 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 comisin 12 Bytes ( Con 2 decimales a la derecha)

Pagos realizados en el sorteo 12 Bytes ( Con 2 decimales a la derecha)

Dinero a recibir, lo que le debe devolver el vendedor 12 Bytes ( Con 2 decimales a la derecha)

Monto total de los tiquetes 12 Bytes ( Con 2 decimales a la derecha)

Deposito 12 Bytes ( Con 2 decimales a la derecha)

Total de ventas de terminales de la banca 12 Bytes ( Con 2 decimales a la derecha)

TABLA 36: RESPUESTA DEL INFORME AL FINAL DEL SORTEO

88
Captura de una respuesta exitosa RX:
12|0|Banca#00|20150730103738|Nac.Noche|12-45-88|0000300|0000300|000000015600|000000000
000|000006000000|-00005984400|000006000000|000000015600|000000015600

ILUSTRACIN 42: TIQUETE DEL INFORME AL FINAL DEL SORTEO

4.6.16 Recargas
Las recargas son una variacin de un tipo de venta, por lo que eventualmente se utiliza el mismo
mapeo transaccional de una venta tanto para envo como para recepcin, lo que se hace es cambiar la
utilizacin de los campos.

ILUSTRACIN 43: PARAMETRO DE RECARGAS

89
Esta trama contiene la siguiente cabecera:
Campo Longitud

Id transaccin "00" siempre venta online para recarga 2 Bytes

STAN(Consecutivo transaccin) 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)

Cdigo generado por el POS 7 Bytes (Solo se usa cuando la venta fue OFFLINE,
normalmente viaja en ceros)
Cdigo de cliente frecuente 5 Bytes

Separador de fin de cabecera 1 Byte @

TABLA 37: ENVO DE RECARGAS

Captura cabecera TX:


00|000017|001|3C039714|00008954871223654878|000002500|20150804184538|0000000|00000@
Despus del separador de '@' se enva 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)

Nmero al que se debe hacer la recarga Variable y depende de la longitud del telfono

TABLA 38: DETALLE DEL ENVO DE RECARGAS

Captura del detalle de la venta:


28|06|0005600|3168828757

90
ILUSTRACIN 44: CONFIRMACIN DE RECARGA

Captura recarga completa con cabecera TX:


00|000017|001|3C039714|00008954871223654878|000002500|20150804184538|0000000|00000@
28|06|0005600|3168828757

Recepcin exitosa RX:


Estructura de la respuesta del servidor:
Campo Longitud
Id Transaccin 2 Bytes
Cdigo de Respuesta 1 Byte (0 exitosa, diferente de 0 es error)
STAN(Consecutivo de la transaccin) 6 Bytes

Cdigo de Autorizacin 10 Bytes ( Impreso en Cdigo de barras)


Nmero 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 recepcin exitosa RX:


00|0|000001|1234892974|1234567|20111228120000|20111228

91
ILUSTRACIN 45: TIQUETE DE RECARGA

4.7 Mensajera ISO 8583

El estndar para transacciones financieras fue implementado en la mensajera del sistema de descarga
remota. Con esto se contempla el manejo de datos sensibles y de estructuracin de un protocolo a
partir de un estndar ISO.

El tiempo de desarrollo se minimiza implementando este protocolo debido a que los datafonos se
comunican con todos los sistemas de autorizacin (Host) utilizando este tipo de estndar. Con este
protocolo se toma la base de esta mensajera y se definen los detalles propios del sistema de descarga
y actualizacin.

ILUSTRACIN 46: MENSAJERIA DE DESCARGA REMOTA TX

92
En la Ilustracin 46 se visualiza la trama ISO 8583 que enva la terminal hacia el servidor. En el
campo encerrado en color azul se muestra el terminal id, su funcin 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 enva el paquete requerido, en este caso es el paquete
nmero 1 del archivo a descargar. Finalmente en el campo de color rojo aparece el tamao mximo
del paquete solicitado por el usuario.

ILUSTRACIN 47: MENSAJERIA DE DESCARGA REMOTA RX

La recepcin del paquete presenta el formato de la Ilustracin 47, donde se visualiza en el campo
encerrado de color azul el terminal id (identificacin del dispositivo), en el campo de color rojo
muestra el progreso de la descarga en este caso es de 1 de 125 paquetes.
El nmero de terminal es el campo clave en la deteccin del dispositivo correcto, adems, el campo
que contiene el nombre de la aplicacin proporciona el dato correcto de la aplicacin que debe tener
instalado ese dispositivo.
El sumario de los campos privados definidos para envi y recepcin de mensajera en formato ISO
8583 se describe en la siguiente tabla.
Tabla Mensaje
A1 Paquete Solicitado
A2 Tamao Mximo del paquete

93
A3 Progreso de la Descarga
!S Nombre del archivo a descargar
K2 Paquete Descargado
41 Terminal ID
TABLA 40: TAGS CAMPO PRIVADO

5. RESULTADOS

5.1 Posibles Fallas o Causas de error

Perdida de los datos descargados dentro del datafono debido a perdida de alimentacin,
reinicio inesperado o falla de comunicacin.
Recepcin errnea de la informacin.
Envo inadecuado de la informacin por parte del servidor.
Exceder la cantidad de datos que se pueden enviar a la impresora trmica.
Interrupcin de procesos por duracin de la batera.
Exceder los campos de respuesta en las consultas y los reportes.
Validacin de ventas offline como total de ventas en el cierre.
Validacin en la generacin de reversos.
Error en la generacin del cdigo de venta del tiquete offline.

5.1.1 Perdida de los datos descargados

5.1.1.1 Prdida de Alimentacin

Los datafonos poseen dos tipos de alimentacin dependiendo su uso, si es un dispositivo mvil su
fuente de alimentacin principal es una batera de litio, por el contrario si es un dispositivo de
escritorio su alimentacin es una fuente de poder externa.

Las bateras de litio se pueden agotar en cualquier momento siempre y cuando el datafono se
encuentre en operacin. La fuente de poder est sujeta a desconexin por errores humanos o fallas en
la red de energa elctrica.

5.1.1.2 Reinicio Inesperado

Los sistemas de comunicaciones poseen estndares y protocolos definidos; sin embargo, existe un
concepto llamado programacin defensiva el cual tiene como objetivo garantizar el comportamiento
de todo elemento de una aplicacin ante cualquier situacin por incorrecta o imprevisible que esta
pueda parecer.

94
El sistema desarrollado tiene un control de excepciones definido el cual cumple con la funcin de
prevenir procesamiento errneo de informacin 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 Comunicacin

La red comunicacin est sujeta disponibilidad del servicio y fallas de los equipos fsicos, esto
provoca una interrupcin del sistema que puede ser permanente o temporal.

5.1.2 Recepcin errnea de la informacin.


La conexin entre dos dispositivos est expuesta a factores externos, ya que en la variedad de medios
ocurren diversos fenmenos que dificultan la adecuada transmisin. Se denomina error a la alteracin
del mensaje recibido con respecto al mensaje transmitido.

Debido a algunos defectos en los medios de transmisin, pueden producirse errores en la informacin
transmitida. La medicin de este error se realiza mediante la tasa de error y se expresa mediante la
relacin entre el nmero de bits errneos recibidos y el nmero total transmitido. Los errores tienden
a agruparse en rfagas, en vez de ocurrir de manera aislada, este aspecto es una ventaja ya que facilita
la deteccin de los errores, de esta manera, afecta a un subconjunto de la informacin transmitida y es
posible reconstruir este subconjunto a partir del resto.

Al aadir unos bits a los paquetes transmitidos, de forma que identifique los errores cuando se
producen, es la manera como se pretende recibir la informacin con la menor cantidad de errores, as
poder ser corregida o simplemente detectada. El modo de obtener la redundancia determina el cdigo
de proteccin frente a errores, hay cdigos capaces de corregir n errores independientes de la posicin
o solamente errores agrupados en un subconjunto de bits.

Para el sistema desarrollado se implementa el mtodo de comprobacin de redundancia cclica (CRC)


y de retrasmisin de paquetes.

La verificacin de informacin a travs del CRC proporciona la posibilidad de validar cada uno de los
paquetes recibidos y descartar paquetes que sufren alteraciones en su trasmisin.

Del desarrollo apropiado de la verificacin del dato CRC surge la necesidad de implementar el
mtodo que haga posible la retrasmisin de un paquete con fallas. Este mtodo de retrasmisin
segmenta la informacin en una cantidad finita de paquetes n, este valor permite solicitar el paquete
exacto que haya sufrido el error durante su trasmisin, con esto se asegura que la informacin a
almacenar en el dispositivo mvil es la esperada sin lugar a errores durante su verificacin.

95
El dispositivo transmisor calcula el CRC aadindole al dato el nmero correcto de ceros. Los datos
se procesan utilizando matemtica binaria. En el siguiente diagrama de flujo se muestra el proceso de
clculo del CRC.

ILUSTRACIN 48: CALCULO DEL CRC

5.1.3 Envo inadecuado de la informacin por parte del servidor

Al existir un envo inadecuado de la informacin por parte del servidor pueden existir un nmero
elevado de excepciones no controladas por parte del datafono, sin embargo gracias al diseo del
protocolo de mensajera, es posible realizar mapeos previos de los campos a utilizar en cada
transaccin. La posibilidad de existir desbordes de memoria es latente, para ello se ha utilizado un
mtodo de errores controlados que permite por medio programacin estructurada validar el tamao de
la porcin de memoria que recibe y la longitud de los datos a recibir. Se realiza una comparacin entre
estos 2 datos y se procede a seguir el proceso correspondiente dependiendo si es exitosa o no la
validacin.

96
5.1.4 Exceder la cantidad de datos que se pueden enviar a la impresora trmica

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 nmero considerable de
jugadas. Este caso fue evidente al realizar un reporte de lista de nmeros en rangos de fechas distantes,
para ello se han canalizado por cdigo los procesos que generalmente podran 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 reciba un carcter a imprimir, pero este
proceso agota la batera porque se debe estar abriendo y cerrando el perifrico de salida (Impresora),
adems de sobrecalentamiento del mismo, la impresora tiene un mximo de 1kB por impresin.

5.1.5 Interrupcin de procesos por duracin de la batera


En cuanto a este tipo de error, lo primero que se debe hacer es identificar los procesos ms
importantes que realizan el sistema y observar que sucede si se cortan de manera sbita. Es claro que
los procesos ms importantes son el envo y la recepcin en una transaccin adems de la impresin
de tiquetes.

En el caso de envo y recepcin el POS enva un reverso de la venta si esta no es percibida y procesada,
en cuanto a la impresin de tiquetes, si se corta en la mitad de una impresin, 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 retransmisin 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 recepcin 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 informacin extra, para ello con ayuda
nuevamente de una programacin defensiva, se ha utilizado la reserva dinmica de memoria que
posee el SDK para tratar esta situacin de la manera ms 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 Validacin 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
hacan cierres y se sincronizaban las ventas, sin embargo haban ventas que nunca lograban realizar la
sincronizacin, se observ que en algunas ocasiones al existir una conexin intermitente y lenta la
transaccin era reversada por timeout, pero en el POS el reverso no era marcado con el mismo

97
consecutivo de salida de venta en el POS. Para esto se hizo revisin paso a paso del cdigo con ayuda
de la herramienta de depuracin 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 Validacin en la generacin de reversos y la sincronizacin


Los reversos segn el entorno bancario deben ser ocasionados siempre que el tipo de transaccin
conlleve al descuento o al abono de dineros a cuentas bancarias, en este caso la cuenta bancaria es el
servidor de Prez 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 lotera. Recordemos que tanto las recargas, como la
venta de apuestas, el batch y la sincronizacin tienen una forma similar en el envo 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 da 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 enve
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 Prez Abreu y
hace que el proceso del POS no tome vital importancia en este proceso.

Adems a lo anterior se suma la cantidad de reversos que se podran presentar sincronizando un lote
de apuestas offline, por ello tambin se implement una transaccin que hace consulta de
sincronizacin, y contrasta cada una de las ventas que se enviaron para sincronizacin en una sola
transaccin 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
transaccin de consulta que es de envo y recepcin, y se marca en el lote ventas si su estado cambi
en el servidor, evitando a toda costa que las mquinas se queden inhibidas en un proceso de reverso
cuando la conexin 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 comunicacin pblico y se registre conexin lenta por la
demanda del mismo, lo que disminuye an ms el porcentaje de reversos presentados en las ventas de
hechas desde el POS.

5.1.9 Error en la generacin del cdigo de venta del tiquete offline


Errneamente 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 cdigo de barras su
autenticidad.

98
Para generar el cdigo de barras se utiliza un cdigo de seguridad que viaja en el detalle de la venta,
este cdigo se genera con un algoritmo llamado "generarNumeroTicket" que realiza una serie de
pasos matemticos que utiliza los siguientes datos a manera de ejemplo:

Serial de la mquina. 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 cdigos similares es mnima,
incluyendo por supuesto el serial de la mquina. En este caso, este algoritmo tambin es validado y
contrasta con la lgica del servidor para verificar la autenticidad de un tiquete offline.

5.2 Descripcin 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


informacin descargada debido a fallas de comunicacin, reinicios, etc. El almacenamiento de la
informacin permite reanudar el sistema a partir de cualquier punto intermedio si se ha visto
interrumpida.

5.2.2 Descompresin

La informacin descargada y almacenada debe ser sometida a un proceso de descompresin, el


mtodo compresin y descompresin implementado en el sistema es el utilizado por el programa
7-zip bajo licencia GNU LGPL.

Este mtodo de descompresin fue modificado de su versin original para su correcto funcionamiento
en espacios de memoria limitados como los tienen los datafonos.

Los siguientes son los pasos de configuracin del datafono:

99
DESCARGA REMOTA

1. PARAMETROS DIAL.
2. NII
3. PARAMETROS IP. Se selecciona opcin 3 para TCP - IP
4. CANT. DATOS

.ILUSTRACIN 49: CONFIGURACIN DESCARGA REMOTA

La interfaz que muestra la configuracin de la IP y el puerto del Host para Descarga Remota
de la siguiente manera:

IP INI 0.0.0.0

Nuevo Valor:
IKKLKL

. . . Especificacin de la IP servidor externo

ILUSTRACIN 50: CONFIGURACIN IP

Puerto Remoto 0000

Nuevo Valor:
IKKLKL

Especificacin del Puerto servidor externo

ILUSTRACIN 51: CONFIGURACIN PUERTO

CONFIGURACION APN

1. CONFIGURACION MANUAL
2. CLARO
3. MOVISTAR
4. TIGO

ILUSTRACIN 52: TIPO DE OPERADOR

100
APN

IKKLKL
Nuevo Valor:

Especificacin APN manualmente


ILUSTRACIN 53:
Ilustracin 20INGRESO MANUAL
Ingresar DE OPERADOR
APN.

La siguiente tabla recopila los valores de tiempos y porcentajes que disminuyeron a la hora de
descargar la aplicacin plana y comprimida.

Archivo Tiempo Tiempo descompresin Tiempo total Relacin del


archivo 7z archivo 7z 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 PRCTICOS DESCARGA GPRS

Lote de Mtodo sin Mtodo con Tipo de Condiciones % de Eficiencia


transacciones implementacin implementacin APN de cobertura en la
offline de consulta de de consulta implementacin
sincronizacin
30 1:58 Minutos 00:48 Minutos Publico Buena 59.43%
10 00:42 Minutos 00:17 Minutos Publico Buena 61,05 %
TABLA 42: IMPLEMENTACIN CONSULTA SINCRONIZACIN

Cantidad de Mquinas con Mquinas con Tipo de APN Condiciones % de Eficiencia


mquinas en reverso sin reverso con de cobertura en la
Repblica mtodo de mtodo de implementacin
Dominicana implementacin implementacin
de consulta de de consulta
sincronizacin
960 288 58 Pblico Aceptable 79.17%
TABLA 43: DISMINUCIN DEL PROCESO DE REVERSO

101
5.3 Variables del Sistema
El anlisis 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 evalan de 1 a 10 siendo 10 el nivel mximo. De
acuerdo a lo anterior la siguiente tabla muestra los valores otorgados a cada una de las variables del
sistema:
Variable Puntaje Observaciones

9 Con la adaptacin de un APN privado se registran tiempos de 1,3


segundos por envo, utilizando un APN pblico se registran tiempos de 5 y
Velocidad de trasmisin
segundos. Notablemente ha mejorado este tem.

10 La capacidad de la batera de 1800mAh hace que sea suficiente para


trabajar con todos los perifricos que posee el sistema embebido, duracin
Duracin de la batera
aproximada de 4300 transacciones de venta seguidas con su impresin
respectiva.

8 Los envos son cortos y no generan un consumo significativo de datos, sin


embargo las respuestas en ocasiones son de una demanda alta de datos,
Consumo de datos por envo
(ms de 2K en un solo envo), lo que genera un mayor costo en el consumo
de datos.

7 En Bogot las pruebas han superado este tem sin mayor dificultad, debido
a la infraestructura mvil que maneja la capital, sin embargo en lugares
Calidad de la comunicacin
aparatados de la capital de Republica Dominicana se han presentado
inconvenientes de cobertura, lo que genera una calificacin media de este
tem.
8 Debido a la regular calidad en la comunicacin en algunos puntos, se ha
optado por estrategias anteriormente mencionadas para disminuir la
Cantidad de reversos
latencia de los mismos, se ha pasado de un 30% de mquinas inhibidas en
generados
reversos por timeout a un 6% del total de las mquinas encontradas en
repblica dominicana.

9 Los tiempos han disminuido notablemente mientras existe una conexin


garantizada, el ejemplo puede ser un lote de 30 apuestas que se hace
Mejora en los tiempos de
offline, estas normalmente en buenas condiciones de cobertura toman
sincronizacin
unos 118 segundos en hacer todo el proceso, con la transaccin
desarrollada esto apenas toma 48 segundos, lo que disminuye el tiempo de
transaccin a menos de la mitad.

10 La implementacin de mtodos de compresin de informacin optimiza el


rendimiento del sistema.
Tamao del archivo de
descarga remota

TABLA 44: VARIABLES DEL SISTEMA

102
Resultado de la valoracin de las variables analizadas en el sistema desarrollado:

Total tems evaluados: 7


Puntaje mximo: 70
Puntaje Obtenido: 61

El porcentaje de rendimiento del proyecto respecto a parmetros ideales es del 87.14%

Este porcentaje es excelente teniendo en cuenta que el parmetro 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 desempeo el sistema desarrollado.

CONCLUSIONES

Es de vital importancia definir cada uno de los mtodos 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 cdigo 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 automatizacin del sistema ha incrementado las ganancias de las casas de
apuestas, y como consecuencia se ha generado ms empleo y no se est fugando el dinero de los
impuestos de Repblica Dominica por apuestas clandestinas.

Es necesario tener en cuenta cuando tenemos una comunicacin bidireccional que el tipo de
mensajera que se disee para hacer el proceso de comunicacin debe ser dinmico, efectivo y
exitoso, la idea de generar conexin entre un servidor y un cliente es reproducir todo de la manera
ms efectiva, sin mayor consumo de recursos y con dinamizacin 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 perifrico
externo del sistema embebido para la generacin de comprobantes o tiquetes puede ser elevado,
alcanzando el lmite mximo 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 impresin en caliente, disminuyendo porcentualmente la
incertidumbre de perder la impresin 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 utilizacin de las terminales POS S90, las cuales vienen precedidas
por sus antecedentes bancarios, y por medio de la cual es posible emplear o utilizar cualquier

103
protocolo de cifrado que este a la altura de las circunstancias debido a su poderoso procesador
criptogrfico.

Cuando se trabaja con un dispositivo que realiza sus procesos de comunicacin inalmbrica
implicando las redes mviles de cada pas, es importante verificar el funcionamiento de las
mismas redes. Esto en cuanto a cobertura, calidad de comunicacin y capacidad de
comunicacin, atenuando cada uno de estos problemas ya sea por una red acceso privada o
certificando la calidad de la red pblica existente. Esto toma su mayor importancia teniendo en
cuenta que la comunicacin inalmbrica es una variable del sistema, la cual al depender de
agentes externos al mismo cdigo del software, puede afectar de manera significativa,
convirtindose en un problema tangible y jams contemplado en el diseo previo.

Al utilizar mtodos de compresin y descompresin de archivos se reduce en un porcentaje


considerable la cantidad de informacin transferida. Con esto se logra disminuir el tiempo que
toma el sistema para transferir la informacin a travs de la red; no obstante, la etapa de
descompresin de informacin tiene un tiempo de procesamiento el cual viene limitado por
varios factores entre ellos estn la cantidad de informacin a descomprimir, la tasa de
compresin, la velocidad de descompresin y la velocidad de almacenamiento.

El mdulo de descarga remota permite actualizar cualquier tipo de informacin, esto indica que
posteriormente es posible implementar este sistema para otro tipo de aplicaciones y otro tipo de
dispositivos, por ejemplo descarga de parmetros adicionales o compresin del mismo ISO 8583.

Como se logra observar en los datos de descarga remota del aplicativo, con la implementacin
del modulo se ha logrado que el tiempo de la actualizacin del aplicativo disminuya en un
63.41%.

El protocolo de comunicacin 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 ms adecuada. Debido a la implementacin de la librera 7Z esto es posible
tambin hacerlo con los datos que viajan al servidor, pero esto tambin requiere de un sistema
complementario que sea capaz de interpretar lo que el POS enva comprimido, el sistema POS es
solo una pequea parte del funcionamiento total del sistema apuestas en Repblica Dominicana.

Es estrictamente necesario el desarrollo de una documentacin adecuada y complementaria al


desarrollo que se ha llevado a cabo, por medio de la misma el usuario podr dimensionar el
potencial y la eficiencia del desarrollo implementado, para ello se ha generado una manual de uso
del aplicativo correctamente especificado.

104
BIBLIOGRAFA

1) 7 Zip. (2012). 7 Zip. Recuperado el 24 de Julio de 2013, de www.7-zip.com


2) Almudena Das, P. M., & Rivas, J. (2007). Anlisis de symbian OS para desarrolar
aplicaciones distribuidas sobre terminales GPRS. Mlaga.
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 solucin tecnologica que
permita la administracin 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: COMUNICACIN 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 Monografas.com:
http://www.monografias.com/trabajos101/proyecto-banca-apuestas/proyecto-banca-apuestas
.shtml
8) CCM. (Junio de 2014). La compresin 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 bsicos de networking.
11) Corporation, M. S. (2009). GPRS. Microsoft Corporation.
12) Crespo Martnez, L. M., & Candelas Heras, F. A. (1998). Introduccin 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 gestin y
administracin de imgenes utilizando tecnologa multimedia GSM. Bogot.
14) Cuevas, J. A. (2007). Modulo didctico de instrumentacin electrnica implementado con
tecnologa FPAA. Bogot, Colombia.
15) Di Mare, A. (1997). Transferencia de archivos durante una conversacin telefnica. San Jose
Costa Rica.
16) Digitalfotored. (2014). Glosario GPRS. Obtenido de digitalfotored.com:
http://www.digitalfotored.com/glosario/gprs.htm

105
17) Dunkels, A. (2006). The uIP Embedded TCP/IP Stack. Estocolomo: Swedish Institute of
Computer Science.
18) ENTEL. (12 de Abril de 2013). Sabes lo que significa WCDMA? Obtenido de
http://comunidad.entel.cl/:
http://comunidad.entel.cl/internet/posts/sabes-lo-que-significa-wcdma
19) Escuela Politcnica Superior de Alcoy (Espaa). (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 Peeherrera, F. P., & Soto Arango, A. F. (2009). Pago electrnico a travs de
telfonos mviles. Guayaquil, Ecuador.
21) Forouzan, B. A. (2002). Transmisin de Datos y redes de comunicaciones 2 Ed.
McGraw-Hill.
22) Galeano, G. (2009). Programacin 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 enseanza de comunicacin. (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) Mrquez, J. B. (2005). Transmisin de Datos. Mrida: Universidad de los Andes.
32) Navarro, G. (Junio de 2001). GPRS: el despegue de la Internet mvil. Recuperado el 10 de
Junio de 2013, de http://www.uoc.edu/web/esp/art/uoc/0105021/berbel_imp.html

106
33) Navarro, R. C. (2010). Instalacin de Linux para ARM en sistemas empotrados. Granada,
Espaa.
34) Oliva Mateos, A., & Sierra Collado, A. J. (Abril de 2006). Aplicacin de Seguridad en
Servicios Web XML para dispositivos mviles mediante la implementacin 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). Domtica 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 - Ingeniera 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 Mxico: 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) Vsquez, J. M. (2002). SSL, Secure Sockets Layer y Otros Protocolos Seguros para el
Comercio Electrnico.
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). Nmeros de puertos. Obtenido de zator.com:
http://www.zator.com/Internet/N_11.htm

107

Anda mungkin juga menyukai