Conexiones concurrentes en obexftp

[bluga]

Hola, estoy implementando una solucion en c para enviar desde mi pub con un portatil archivos de imagenes para promocionarme.No se porque mi pub con lo chulo que esta no entra mucha gente y al lado tengo 2 mas cutres y siempre estan llenos.

Utilizo 3 bluetooth por usb, uno lo utilizo para escanear dispositivos y guardar las macs con su canal en un fichero y los otros dos para envio. El problema reside en la velocidad y el tiempo de envio. 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.
Implemento el envio con el obexftp, a groso modo:
cli = obexftp_open(OBEX_TRANS_BLUETOOTH, NULL, NULL, NULL);
ret = obexftp_connect_src(cli,dir,MAC,canal,NULL,0);
ret = obexftp_put_file(cli,f,ft);
obexftp_close(cli);
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. Por cada envio utilizo un proceso pesado (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?
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.
Muchas gracias, un saludo, el foro esta genial.

[SirGraham]

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.

[bluga]

Gracias por tu pronta respuesta. A ver si te he entendido bién:
digamos que pillo 7 moviles con sus respestivos canales, se supone que "teoricamente" puedo ir realizando envíos por sus respectivos canales a los 7 a la vez, solo necesito 7 macs y 7 canales.
Estaba un poco confundido con este tema pero creo que me lo aclaras. Probaré a usar threads a ver que tal.
Muchas gracias por todo

[SirGraham]

Hola,

Para que lo entiendas es asi. Tu con un modulo, por protocolo de Bluetooth, puedes abrir 7 conexiones hacia 7 modulos de Bluetooth (diferentes o no). Pero eso es en teoria. En la practica no es asi.

¿Por que ? por que el modulo balancea el ancho de banda que tiene disponible y si no queda no abre conexion. Esto mas que en el OBex se ve con un canal de Voz (que "chupa" mucho ancho de banda). Si tu abres un canal voz en un Bluetooth 2.0 (3MBits de ancho de banda) poco mas vas abrir. Pero si lo haces en Bluetooth 1.2 olvidate de abrir nada mas ... ni incluso una simple conexion con el SDP.

Por otra parte:

"Los Threads poderosos son, pero mucho cuidado con ellos debes tener...."
Maestro Zoda.
Star Bytes.

No hay nada como los threads para tener unos enormes dolores de cabeza.... que lo sepas. En muchas ocasiones hay que usarlos (mejor solucion). Pero a la hora de desarrollar debes pensar en multiproceso... no linealmente...  si no te va salir un churro...


Saludos,
Sir Graham.