I have two java programs using JSR 82 (as implemented by bluecove 2.1.x) to communicate between two windows machines. One implements the server side and one is the client side. All works well most of the time. I can successfully discover, read and write, etc. Almost no problems.
A problem arises when I try to optimize the connection process. As an optimization, I have the client record the discovered connection url so that it can be cached and re-used in subsequent connections (after machine goes thru a power cycle, for example). The urls look something like this:
btspp://1C4D89CB4921:1;authenticate=true;encrypt=true;master=false
These urls are normally obtained through the bluetooth discovery process whereby the client makes inquiries of the server. The specific api that yields the urls is javax.bluetooth.ServiceRecord getConnectionUrl().
Normally I can re-use such a url and reliably re-connect to the original server bypassing the discovery process. But under certain conditions (and I don't know what they are) the channel identifier of a server may change. I've highlighted the channel identifier in the sample url below.
btspp://1C4D89CB4921:1;authenticate=true;encrypt=true;master=false
Almost always, in my experience, the channel identifier is 1. But not always. And even through I control the server code as well as the client, I don't have any control over the channel number as far as I can tell.
So my question: Is there a way to control (or predict) the channel number, preferably using only JSR-82? Or even more generally, why do we need channel numbers in the first place and how does the bluecove 2.1.x implementation choose them.
