It would be good if BTdaemon support TCP socket (it's currently running with unix socket). I already implemented option support for BTdaemon, libBTstack will be implemented soon.

Please take a look in the uploaded patch.

Here's another patch, I made bt_open() to support more 2 arguments (socket mode and host for TCP mode), I also update all related code (test.c, rfcomm.c, WiiMote demo and many more.

hi again. From your comment at GettingStarted, I understand you want to use the physical BT of the iPhone from an app in the simulator. Very well, for people without a serial BT module this makes a lot of sense. I've used that model before, too :)

I'm a bit opposed to changing the bt_open call, if not really necessary. Instead, we could add an additional configure call like bt_set_tcp_host(adddress, port). But that also requires changing all apps.

What about adding a configure option for this case like --with-tcp-host --with-tcp-port and current unix socket as default?. Then, the code does not need to be changed, but will work nevertheless. The knowledge about where the BTdaemon is would be hidden in the libBTstack.dylib..

Does this makes sense?

I agree with you about bt_open() function, it should not be modified unless necessary.

To have TCP option on libBTstack, I prefer bt_set_tcp_host(address, port). If user doesn't call this function, bt_open() should work as it used to be (unix socket by default).

I don't feel comfortable with configure parameter because I will have to recompile libBTstack every time my iPhone/iPod changes its IP address (i.e. DHCP). If host and port can be defined directly in an application level, some application may be able to select its BTdaemon server on the fly, I think it may be useful.

BTW, I hope option.patch is still useful. It adds --tcp and --help option to BTdaemon to start BTdaemon in TCP socket mode (using default port 13333). This removes one of your @TODO :)

After a little more thinking about this, I think making bt_set_tcp_host() may make some people confused about default behavior of bt_open(). Instead, creating a new bt_open_xxx() would be better, to keep bt_open() untouched and let those who want to use TCP socket call a new bt_open_xxx().

What should I name it? - bt_open_ex(mode, host, port) - bt_open_opt(mode, host, port) - bt_open_...

hi. i decided on a bt_use_tcp() configuration call as it is easier to comment out (e.g. when switching between simulator and device) and the code of bt_open does not need to be duplicated for the tcp variant.

It's commited to SVN, please have a look.

Well, that seems to work well. thx

Thanks for pushing that feature. :)

I'll try to see if a socket/tcp dual-configuration is possible with launchd, so that both are supported in the default Cydia package.

hi. I've cleaned up a bit and BTdaemon is now able to accept connections on two different sockets, e.g., tcp 13333 and unix /tmp/BTstack at the same time when launched by launchd. if you want, copy resources/ch.ringwald.BTstackTCP.plist into /Library/LaunchDaemon and activate it with launchctl load /Library/LaunchDaemons/ch.ringwald.BTstackTCP.plist - after deactivating ch.ringwald.BTstack.plist.

btw. even from the command line, BTdaemon could listen on tcp and unix, when socket_connection_create_tcp and socket_connection_create_unix are both called.