>> The first idea that came to my mind was to introduce a random value
>> generated by both devices, which comparision (higher/lower) determines
>> which device will be the connector and which one the connectee.
>>
>> Another is to implement the old ALOHA method: detect a failure in
>> connection and than wait a random time before attempting to make another
>> connection -- but listen for an attempted connnection while waiting.
>
> Coming up with a random delay can be problematic in identical units that
> get powered up at the same time, but shouldn't each Bluetooth device have
> a unique MAC? You could use that to seed your random number generator.
>
In two truly unique devices without a serial number, a useful trick is
to calculate a checksum over the memory/register contents before they
are initialized.
Reply by John Speth●April 24, 20142014-04-24
> I have a Bluetooth inquiry/response connection problem for which I
> suspect there is a classic solution. I just can't seem to find the
> answer so I hope somebody here can offer a solution. The problem domain
> is Bluetooth but I don't think that should be a limiter in finding the
> solution.
Thanks to everyone with the useful discussion. The excellent and simple
suggestion to use the 48 bit Bluetooth address as a comparison to
determine who shall be connector and connectee works perfectly. It
works well in the BT domain because BT address is one of a few items
that is shared over air during scanning prior to connection.
John Speth
Reply by R.Wieser●April 22, 20142014-04-22
Tim,
> but shouldn't each Bluetooth device have a unique MAC?
> You could use that to seed your random number generator.
If that MAC value is unique (which is not a given!), why use it as a seed at
all ? Just comparing it (in accordance with my first suggestion) would than
be enough.
But you're right. The ALOHA method needs a well seeded and working random
generator. Otherwise the not unthinkable situation of synchronized random
values could occur ....
Regards,
Rudy Wieser
P.s.
> (top posting fixed)
bottom posting fixed.
(A passive-agressive response to a passive-agressive remark)
-- Origional message:
Tim Wescott <tim@seemywebsite.really> schreef in berichtnieuws
XdWdnbLgAoCCAcvOnZ2dnUVZ5oWdnZ2d@giganews.com...
> On Tue, 22 Apr 2014 13:55:23 +0200, R.Wieser wrote:
> (top posting fixed)
> >
> > -- Origional message:
> > John Speth <johnspeth@yahoo.com> schreef in berichtnieuws
> > lj4i1f$6kr$1@speranza.aioe.org...
> >> Hi Folks-
> >>
> >> I have a Bluetooth inquiry/response connection problem for which I
> >> suspect there is a classic solution. I just can't seem to find the
> >> answer so I hope somebody here can offer a solution. The problem
> >> domain is Bluetooth but I don't think that should be a limiter in
> >> finding the solution.
> >>
> >> Device A and B are Bluetooth devices that must find each other but only
> >> one can be the "connector" and hence the other must be the "connectee".
> >> The problem is that both A and B must advertize as peers before they
> >> connect (same advertizement IDs) and when one finds the other it
> >> attempts to connect to the other. Usually the situation works
> >> (connector finishes connecting to the connectee and then the connectee
> >> stops advertizing). The bad situation happens when both devices
> >> attempt to operate as connectors (not connectees) because they both
> >> found each other at nearly the same time.
> >>
> >> It's like a bunch of devices trying to join a party but each are
> >> obligated to conform to an invite / accept protocol. Failing that
> >> protocol represents a broken design.
> >>
> >> Can someone offer how systems like this would solve this problem? Even
> >> offering some useful engineering vocabulary so that I can search the
> >> web would be helpful.
> >>
> >> I hope I gave a clear explanation of my needs. Thanks for helping.
>
> > Hello John,
> >
> >> Can someone offer how systems like this would solve this problem?
> >
> > The first idea that came to my mind was to introduce a random value
> > generated by both devices, which comparision (higher/lower) determines
> > which device will be the connector and which one the connectee.
> >
> > Another is to implement the old ALOHA method: detect a failure in
> > connection and than wait a random time before attempting to make another
> > connection -- but listen for an attempted connnection while waiting.
>
> Coming up with a random delay can be problematic in identical units that
> get powered up at the same time, but shouldn't each Bluetooth device have
> a unique MAC? You could use that to seed your random number generator.
>
> --
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
Reply by ●April 22, 20142014-04-22
On 22.04.2014 03:52, John Speth wrote:
> The bad situation happens when both devices attempt
> to operate as connectors (not connectees) because they both found each
> other at nearly the same time.
That's a well-known complication which became somewhat notorious in the
early days of Auto-MDI-X in 10/100BaseT Ethernet. Things would work
just fine almost all the time, _except_ in some strange cases, when you
tried to connect two devices using the exact same implementation,
particularly if they were turned on synchronously. They could never
agree which of the two should cross/not cross the lines, because they
would both flip their own state at the exact same time, every time, ad
nauseam. In effect they would fail to establish a link although there
was really not the slightest thing wrong with the cabling.
> It's like a bunch of devices trying to join a party but each are
> obligated to conform to an invite / accept protocol.
Actually, it's more like the age-old problem of two people walking
directly towards each other in the street. Usually one of them will
dodge to one side just as the other dodges to the other, or one reacts
correctly to a barely perceived dodge of the other, and they'll just
pass each other by uneventfully. And yet, every once in a while two
people actually run headlong into each other, or avoid it only by an
emergency full stop. When that happens it's because they both picked
the exact same evasive manoeuvre, at the exact same time, every time.
The same pattern can emerge when two people of equal upbringing try to
pass the same narrow doorway simultaneously. They may be stuck there
for an improbably long time without either making it through, either in
an endless loop of mutually asserting: "Ah but I could not possibly
impose! Please: after _you_, sir!", or repeatedly trying to pass in the
exact same moment, bodily blocking each other's passage.
This failure mechanism of collision avoidance can't be avoided by any
rigid protocol. You really have to inject _some_ kind of difference
between participants into the mix, to break out of the symmetry trap.
As Tim and Rudy already indicated, the two primary sources of such
difference are device IDs (MAC, ...) and true random numbers.
>
> -- Origional message:
> John Speth <johnspeth@yahoo.com> schreef in berichtnieuws
> lj4i1f$6kr$1@speranza.aioe.org...
>> Hi Folks-
>>
>> I have a Bluetooth inquiry/response connection problem for which I
>> suspect there is a classic solution. I just can't seem to find the
>> answer so I hope somebody here can offer a solution. The problem
>> domain is Bluetooth but I don't think that should be a limiter in
>> finding the solution.
>>
>> Device A and B are Bluetooth devices that must find each other but only
>> one can be the "connector" and hence the other must be the "connectee".
>> The problem is that both A and B must advertize as peers before they
>> connect (same advertizement IDs) and when one finds the other it
>> attempts to connect to the other. Usually the situation works
>> (connector finishes connecting to the connectee and then the connectee
>> stops advertizing). The bad situation happens when both devices
>> attempt to operate as connectors (not connectees) because they both
>> found each other at nearly the same time.
>>
>> It's like a bunch of devices trying to join a party but each are
>> obligated to conform to an invite / accept protocol. Failing that
>> protocol represents a broken design.
>>
>> Can someone offer how systems like this would solve this problem? Even
>> offering some useful engineering vocabulary so that I can search the
>> web would be helpful.
>>
>> I hope I gave a clear explanation of my needs. Thanks for helping.
> Hello John,
>
>> Can someone offer how systems like this would solve this problem?
>
> The first idea that came to my mind was to introduce a random value
> generated by both devices, which comparision (higher/lower) determines
> which device will be the connector and which one the connectee.
>
> Another is to implement the old ALOHA method: detect a failure in
> connection and than wait a random time before attempting to make another
> connection -- but listen for an attempted connnection while waiting.
Coming up with a random delay can be problematic in identical units that
get powered up at the same time, but shouldn't each Bluetooth device have
a unique MAC? You could use that to seed your random number generator.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by R.Wieser●April 22, 20142014-04-22
Hello John,
> Can someone offer how systems like this would solve this problem?
The first idea that came to my mind was to introduce a random value
generated by both devices, which comparision (higher/lower) determines which
device will be the connector and which one the connectee.
Another is to implement the old ALOHA method: detect a failure in connection
and than wait a random time before attempting to make another connection --
but listen for an attempted connnection while waiting.
Regards,
Rudy Wieser
-- Origional message:
John Speth <johnspeth@yahoo.com> schreef in berichtnieuws
lj4i1f$6kr$1@speranza.aioe.org...
> Hi Folks-
>
> I have a Bluetooth inquiry/response connection problem for which I
> suspect there is a classic solution. I just can't seem to find the
> answer so I hope somebody here can offer a solution. The problem domain
> is Bluetooth but I don't think that should be a limiter in finding the
> solution.
>
> Device A and B are Bluetooth devices that must find each other but only
> one can be the "connector" and hence the other must be the "connectee".
> The problem is that both A and B must advertize as peers before they
> connect (same advertizement IDs) and when one finds the other it
> attempts to connect to the other. Usually the situation works
> (connector finishes connecting to the connectee and then the connectee
> stops advertizing). The bad situation happens when both devices attempt
> to operate as connectors (not connectees) because they both found each
> other at nearly the same time.
>
> It's like a bunch of devices trying to join a party but each are
> obligated to conform to an invite / accept protocol. Failing that
> protocol represents a broken design.
>
> Can someone offer how systems like this would solve this problem? Even
> offering some useful engineering vocabulary so that I can search the web
> would be helpful.
>
> I hope I gave a clear explanation of my needs. Thanks for helping.
>
> John
Reply by John Speth●April 21, 20142014-04-21
Hi Folks-
I have a Bluetooth inquiry/response connection problem for which I
suspect there is a classic solution. I just can't seem to find the
answer so I hope somebody here can offer a solution. The problem domain
is Bluetooth but I don't think that should be a limiter in finding the
solution.
Device A and B are Bluetooth devices that must find each other but only
one can be the "connector" and hence the other must be the "connectee".
The problem is that both A and B must advertize as peers before they
connect (same advertizement IDs) and when one finds the other it
attempts to connect to the other. Usually the situation works
(connector finishes connecting to the connectee and then the connectee
stops advertizing). The bad situation happens when both devices attempt
to operate as connectors (not connectees) because they both found each
other at nearly the same time.
It's like a bunch of devices trying to join a party but each are
obligated to conform to an invite / accept protocol. Failing that
protocol represents a broken design.
Can someone offer how systems like this would solve this problem? Even
offering some useful engineering vocabulary so that I can search the web
would be helpful.
I hope I gave a clear explanation of my needs. Thanks for helping.
John