Hola,
Siempre lo decimos...
"No es lo mismo enviar por bluetooth... que hacer Marketing de proximidad..."Me da que Bluga lo acaba de comprobar cual es la diferencia del tema. Es facil realizar un envio por bluetooth, pero cuando vas a realizar una aplicacion "efectiva" de marketing de proximidad (con las necesidades que ello con lleva) veras que el margen de diseño y gestion se vuelve "mas complicado".
El tiempo que tarda en escanear y enviar a 4 moviles por ejemplo es de unos 40 segs y esto es las mejores condiciones (moviles a los que le he pillado bien el canal y todos al lado de los bluetooth usb), y claro yo lo que quiero captar es a gente que esta andando por la calle y esta solución no me sirve mucho puesto que pierdo a muchos moviles por el tiempo que se tarda.
Evidentemente es necesario realizar unas optimizaciones para que esa gestion "sea mas adecuada". Hay cosas que desgraciadamente no te puedo comentar (dado que es una pieza competitiva de nuestro software) pero te dire que
SI ES factible mejorar esos procesos.
Estas son basicamente las sentencias que utilizo, uso un doble for,uno para recorrer cada uno de las 7 conexiones concurrentes que teoricamente soporta el bluetooth y otro para recorrer el hci 1 y el hci2.
Eso no tiene mucho sentido o yo no lo acabo de entender.
¿No es mejor ir ocupando los canales segun los terminales que has encontrado?(obviamente solo los factibles de realizar el envio).
¿Para que "recorrer" las posibles conexiones que dispones?.
Acaso ¿No sabes cuantas estas usando?
Por otra parte que puedas realizar 7 conexiones en bluetooth no quiere decir que te ancho de banda del modulo te de para hacerlo. El Modulo de bluetooth balancea el ancho de banda entre las conexiones abiertas y a poco grande que sea el archivo no vas a llegar a las 7 "ni de coña". Vamos ni tu ni nadie...
En multiples ocasiones hemos explicado aqui que los que usan como "gancho" comercial" para vender su herramienta el de que llegan hasta 21 conexiones concurrentes (con 3 modulos x 7 conexiones = 21) ESTAN MINTIENDO DESCARADAMENTE....
Primero por que no buscarian mientras envian (con lo que ello con lleva). Segundo por que si estas enviando ya por unos canales, el modulo no te abre mas si ve que estas consumiento el ancho de banda disponible...
Por cada envio utilizo un proceso pesado (fork).
Horror!!!!!
¿Por que? Acaso usas aplicaciones externas para el envio? Para que necesitas usar un Fork?
No se donde indicarle que me haga un envio por la conexión 1 y otro por la 2 asi hasta 7. Y tampoco se si implementarlo mejor con threads en vez de con fork.¿podeis orientarme?
Las conexiones las crea el modulo segun se las vas pidiendo. Evidentemente un Thread es infinitamente menos pesado que un Fork.
Nuestra implementacion del
XBlue Point en Linux (que la tenemos) usando 3 modulos bluetooth (el maximo que solemos poner) lleva a consumir de un 0.4 a un 0.7% del proceso de la maquina....
La duda que me trae mas loco es si se puede controlar a nivel de codigo con el obexftp o con otra cosa el tema de las conexiones simultanteas, o eso lo hace automaticamente el hardware del bluetooth.
Lo haces tu... el modulo no tiene conexiones "automaticas" sean simultaneas o no...
Nosotros llevamos "años" (desde 2004) haciendo I+D+i en ese tema...
Bienvenido... pero como estas comprobando te queda un largo camino por recorrer (me temo)... 
Saludos,
Sir Graham.
Mostrar Mensajes
Gracias. Pues es el Txiki de la familia. Una version economica de nuestros 
... mas que el puro envio por Bluetooth.
