2017-07-17 21:14:45

by Olivier MARTIN

[permalink] [raw]
Subject: AcquireWrite & AcquireNotify

Hi all,
After exchanging a couple of emails about MTU on the mailing-list last
week, Luiz suggested the new functions AcquireWrite() & AcquireNotify()
would do the job. I wanted to give a try and I changed my application
protocol to take advantage of them.

But I have just realized they are both for the client side but I am
using Bluez on the GATT server side. I am a bit worry to come back to my
initial issue where I was thinking I will need the MTU... How can I send
the longest GATT notification from the GATT server (in the context of a
DBUS-based application)?

Thanks in advance,
Olivier


2017-07-18 12:23:32

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: AcquireWrite & AcquireNotify

Hi Olivier,

On Tue, Jul 18, 2017 at 12:14 AM, Olivier MARTIN <[email protected]> wrote:
> Hi all,
> After exchanging a couple of emails about MTU on the mailing-list last week,
> Luiz suggested the new functions AcquireWrite() & AcquireNotify() would do
> the job. I wanted to give a try and I changed my application protocol to
> take advantage of them.
>
> But I have just realized they are both for the client side but I am using
> Bluez on the GATT server side. I am a bit worry to come back to my initial
> issue where I was thinking I will need the MTU... How can I send the longest
> GATT notification from the GATT server (in the context of a DBUS-based
> application)?

Well the server don't really need to restrict access since it is only
accessed by bluetoothd, though the notification is not 1:1, so if you
change the Value bluetoothd will send the data to all connected peers
with notifications enabled.

I guess the right the most efficient thing to do would make fd passing
for the server as well, though AcquireWrite/AcquireRead would not work
as intended there since the one passing down the fd would be the
application itself not bluetoothd. For things like WriteValue we end
up extending the parameters with a dictionary and then have server
only options, like Device an MTU, though the fd has still to be
returned, but this may not be a bad idea after all since the app would
be able to control exactly where it wants bluetoothd to write to.

> Thanks in advance,
> Olivier
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
Luiz Augusto von Dentz