Archived
This forum has been archived. Please start a new discussion on GitHub.
Bluetooth endpoint for Ice 3.3
in Help Center
Hello,
I've written a plugin for Ice 3.3 consisting in an bluetooth endpoint. It supports only RFCOMM profile (for now...). The endpoint format is:
bt -a "XX:XX:XX:XX:XX:XX" -c XX
Where -a specifies hci's mac and -c indicates the channel. If -a it's omited, BDADR_ANY is assumed (only on server side, clients throw an exception).
The endpoint works fine, but some problems occur:
- On local invocations, when communicator goes througth the loopback interface, the endpoint fails because the HCI doesn't have this special device. In languages that supports "collocated" objects this problem seems to disappear.
- On reverse invocations (for example: a client sends callback to server and the server calls the cb) the endpoint fails (It throws a "Device busy exception"). I don't have any idea about this issue, but I think this:
1) start server: server's side endpoint creates acceptor. Lock hci.
2) start client: client's side endpoint creates connector. Lock hci.
3) client sends CB.
4) Server invokes CB but hci is locked and connector creation fails.
I guess this problem could be caused because the collocated object doesn't re-use the same connection... rigth?
Test programs are written in Python and I have developed the plugin under Debian Unstable (with Ice3.3.1 and Bluez 4.53)
All code is written under GPL license but I haven't published it yet. If you want it I can release it on some repository.
Thank you in advance.
I've written a plugin for Ice 3.3 consisting in an bluetooth endpoint. It supports only RFCOMM profile (for now...). The endpoint format is:
bt -a "XX:XX:XX:XX:XX:XX" -c XX
Where -a specifies hci's mac and -c indicates the channel. If -a it's omited, BDADR_ANY is assumed (only on server side, clients throw an exception).
The endpoint works fine, but some problems occur:
- On local invocations, when communicator goes througth the loopback interface, the endpoint fails because the HCI doesn't have this special device. In languages that supports "collocated" objects this problem seems to disappear.
- On reverse invocations (for example: a client sends callback to server and the server calls the cb) the endpoint fails (It throws a "Device busy exception"). I don't have any idea about this issue, but I think this:
1) start server: server's side endpoint creates acceptor. Lock hci.
2) start client: client's side endpoint creates connector. Lock hci.
3) client sends CB.
4) Server invokes CB but hci is locked and connector creation fails.
I guess this problem could be caused because the collocated object doesn't re-use the same connection... rigth?
Test programs are written in Python and I have developed the plugin under Debian Unstable (with Ice3.3.1 and Bluez 4.53)
All code is written under GPL license but I haven't published it yet. If you want it I can release it on some repository.
Thank you in advance.
0
Comments
-
...
I guess this problem could be caused because the collocated object doesn't re-use the same connection... rigth?
...
With Ice co-located means that the client & server use the same communicator object (this has the obvious implication that the client & server are in the same process). I suspect that isn't what you mean here correct?
It you want to re-use the same connection for callbacks, you should be using bi-directional connections. Did you look at the demo/Ice/bidir demo?0 -
Probing demos...
I tested bidir demo (in C++ and Python) with bluetooth endpoint and it works, but my problem is a little different.
For example, this code:
adapter = self.communicator().createObjectAdapter('Printer')
printerCB = adapter.add(Servant(), self.communicator().stringToIdentity('helloPrinter'))
adapter.activate()
printerCB.ice_ping()
return 0
Despite of printerCB is a local object (it is co-located, isn't it?), the invocation is sent througth the loopback interface instead of direct invocation. This occurs at least on python and this fails with bluetooth endpoint because hci doesn't have loopback interface.
However, bidir demo doesn't have local invocations because it passes an Identity object, not a Proxy (wich might need checkedCast()).
Thanks.0 -
Hi,
Collocation optimization isn't supported with Ice for Python so the behavior you're seeing is expected: despite the fact that the printerCB Ice object is collocated, the invocation tries to establish a connection using the proxy endpoint.
For this to work, you would need to add support for loopback communication directly to your transport plugin (by using a TCP/IP socket listening on 127.0.0.1 for example). Another option would be to configure the object adapter to also listen on 127.0.0.1, this way, collocated invocations should be able to use a TCP/IP connection to 127.0.0.1 if the bluetooth connection fails.
Cheers,
Benoit.0
