[Thali-talk] Yaron's Weekly Update - 9/8/2014

Yaron Goland yarong at microsoft.com
Mon Sep 15 13:26:05 EDT 2014


O.k. so now all the pieces seem to fit together. I updated the blog article http://www.goland.org/thalimesh/

Thanks for answering my endless questions. I'm bummed that the situation is such a mess but I have to think it's just going to get better.

Thanks,

    Yaron    


________________________________________
From: Michael Rogers <michael at briarproject.org>
Sent: Saturday, September 13, 2014 5:25 AM
To: Yaron Goland
Cc: thali-talk at thaliproject.org
Subject: Re: [Thali-talk] Yaron's Weekly Update - 9/8/2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/09/14 17:14, Yaron Goland wrote:
> For me there are two different issues.
>
> Question One - How did you get the UUID?
>
> Question Two - How do you opportunistically connect to whomever
> may be around via Bluetooth?
>
> The answer to question one is - not via Bluetooth unless you want
> to display a UX. That's fine for Thali. We have lots of other ways
> to move the UUID around so I'm not worried. We currently use
> QRCodes, we will soon support email and we will also probably
> support NFC.

The UUID can be hard-coded, there's no need to move it around. Briar
uses one UUID per device to make it harder to identify Briar traffic,
but the standard thing is to generate a UUID for your app and
hard-code it.

I'd ask these questions instead:

* Do I want to connect to specific devices, or any Thali device that's
nearby?

* If specific devices:
  + How do I get the MAC addresses? (QR codes, email, NFC)
  + How do I know when those devices are nearby? (Discovery, blind
groping)

* If any Thali device:
  + How do I get the MAC addresses? (Discovery)
  + How do I tell which devices run Thali? (SDP, blind groping)

> The answer to question two seems to be - Brute Force. So if I have
> an address book with 200 people in it then to support
> 'opportunistic' networking we have to permanently brute force
> through all 200 entries trying to get a insecure RF Comm socket. I
> have no idea what the battery consequences of this are. If the
> device is 1/2 intelligent it should be 'free'. They should have a
> local SDP database and the queries should be hitting that before it
> hits the 'wire'. But I just don't know.

There's no way to make it free. If you want to know who's nearby then
either they have to send out periodic beacons of some kind, or you
have to send out queries of some kind. Either way, somebody's
transmitter is getting turned on.

As far as I know, Bluetooth doesn't send out beacons. If you want to
know who's nearby you have to query. You can do that by running
discovery or by trying to connect to a specific address. Discovery
will only find devices that are discoverable.

Making 200 connection attempts periodically is going to be expensive,
I agree. Whether it's more or less expensive than running discovery
periodically I don't know - but it's a moot point because we can't
make Android devices permanently discoverable, so discovery won't find
them anyway.

> I caught your comment about using private APIs to get to SDP but
> that makes me uncomfortable. It's the sort of approach that is
> ridiculously fragile and leads to endless support issues.

Yeah, it sucks. I wouldn't contemplate dirty hacks like this if there
were a decent ad hoc networking API we could use.

> So my question to you is - Briar's bluetooth polling seems to be
> what I describe in question two above. Do you only run polling in
> the foreground (e.g. if the user is actively using the Briar app)
> or do you run it in the background all the time? We would want to
> do the later to support opportunistic synching. Do you have any
> idea what the battery consequences are?

We run it in the background all the time. Right now it does the
simplest thing: every few minutes, it tries to connect to every
address it knows. We can probably improve on that, but we'll need to
set up an experimental testbed with multiple devices and battery life
measurement and gah.

One simple way to reduce the battery consumption is to allow the user
to turn on Bluetooth selectively when they're near their contacts.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUFDe7AAoJEBEET9GfxSfMHZYH/jU83WHmJwuSYVNQGfyr1NHH
Qc2LHAZSkRRa/vab3/zCBBcTYF98kOr/XUR/133IX9PUO//UfogG3IoUZk9ZAk1M
lEnonJPKCCtONjLfJ+a+atKkehLevxeHmElkm+8Q34yBew87h9hOiO8IpnEHgkw4
rld7GIRiHUYJxAtR1BwNj12AQNVO9FUxmSXLyhge/364Du0Nzr676S8faogq6ALN
2vcJ0ANA3TFMK1zjpJL2IDuhKuK8/Qzq5B7OQ5BZyP5YEgF2Uvn7qc29wqR4Q/9s
UlZhj3CzzH7UOuQyMefRZqeLCo+4bs88DmVVkry1Sjn0RndYrw65x7dmkq21ruE=
=SI3a
-----END PGP SIGNATURE-----


More information about the Thali-talk mailing list