Return-Path: From: Jonah Petri Message-Id: <04050C11-F780-4C5C-A49E-1B3DFEEFA066@sense.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_31F8CAEC-B1F8-4D3A-91FC-1F4E059C865B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] gatt-server: Implement NegotiatedMTU property on Device1 Date: Tue, 18 Jul 2017 08:40:53 -0400 In-Reply-To: Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" To: Marcel Holtmann References: <8E72D5C7-FA44-4B06-82D7-2FCB22E26778@holtmann.org> <1A61FCA4-F476-456F-AAAE-3C7753885BD4@holtmann.org>

List-ID: --Apple-Mail=_31F8CAEC-B1F8-4D3A-91FC-1F4E059C865B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Marcel, > On Jul 18, 2017, at 2:42 AM, Marcel Holtmann = wrote: >=20 >>>> The negotiation of the MTU can be a significant event to the client = interacting via dbus, so how should the completion of that negotiation = be exposed, if not via an attribute as I proposed above? Some boolean = "MaxPayloadNegotiationCompleted" method? >>>=20 >>> there will be PropertiesChanged signal once the MTU has been = altered. Otherwise it will start out with 23 in case of LE or the = minimum of whatever L2CAP has configured for BR/EDR. We do the same for = RFCOMM btw. where it takes the minimum value from the two MTUs. >>>=20 >>=20 >> I understand. However, there is no way for a dbus client to tell the = difference between these two scenarios: >>=20 >> 1) The MTU has been negotiated to 23 (in the case of LE) >> 2) The MTU negotiation has not been completed >>=20 >> I expect many clients making use of this information will want to = wait until the MTU negotiation is complete, and then begin normal = operation. A single attribute representing the current MTU seems to not = be sufficient to implement such a dbus client. >=20 > the other option is to leave the property out until the MTU has been = negotiated. So in case of LE and Exchange MTU has not yet happened, that = property does not exist. In BR/EDR it will always exist since L2CAP has = finished already. >=20 > So clients can start whenever they see the PropertiesChanged signal or = get the property in the first place. >=20 This seems fine to me. Thanks for the feedback. I will submit a new = patch. Jonah --Apple-Mail=_31F8CAEC-B1F8-4D3A-91FC-1F4E059C865B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Marcel,

On Jul 18, 2017, at 2:42 AM, = Marcel Holtmann <marcel@holtmann.org> wrote:

The negotiation of the = MTU can be a significant event to the client interacting via dbus, so = how should the completion of that negotiation be exposed, if not via an = attribute as I proposed above? Some boolean = "MaxPayloadNegotiationCompleted" method?

there will be PropertiesChanged signal once the MTU has been = altered. Otherwise it will start out with 23 in case of LE or the = minimum of whatever L2CAP has configured for BR/EDR. We do the same for = RFCOMM btw. where it takes the minimum value from the two MTUs.

I understand. = However, there is no way for a dbus client to tell the difference = between these two scenarios:

1) The MTU has = been negotiated to 23 (in the case of LE)
2) The MTU = negotiation has not been completed

I expect = many clients making use of this information will want to wait until the = MTU negotiation is complete, and then begin normal operation. A = single attribute representing the current MTU seems to not be sufficient = to implement such a dbus client.

the other option is to leave the property out = until the MTU has been negotiated. So in case of LE and Exchange MTU has = not yet happened, that property does not exist. In BR/EDR it will always = exist since L2CAP has finished already.

So clients can start whenever they see the = PropertiesChanged signal or get the property in the first = place.

This seems = fine to me. Thanks for the feedback. I will submit a new = patch.

Jonah

= --Apple-Mail=_31F8CAEC-B1F8-4D3A-91FC-1F4E059C865B--