Hi Luiz, Den sön 1 mars 2020 kl 07:46 skrev Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx>: > > Hi Emil, > > On Sat, Feb 29, 2020 at 2:13 AM Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote: > > > > Hi. I have a feature request that the negotiated ATT MTU should be > > exposed as a property in the org.bluez.Device1 interface. > > > > For some applications it's good to know or required how much data that > > can be written / read / notified in each packet, and it's not always > > desired or possible to use AcquireNotify / AcquireWrite. > > We already negotiate a fairly big MTU maximum by default, and you can > just use AcquireWrite/AcquireNotify just to discover it and the close > the fd immediately, so I suppose we cover much of what the feature is, I was considering having a solution implementable by for example Web-Bluetooth. This "workaround" wouldn't always work since it's not guaranteed to exist a characteristic with the 'write-without-response' or 'notify' property. I think there could also be a "race condition" here if two apps do the same thing (although the time window is pretty small): one app might get that the acquire operation returned "busy". And is it even possible to use AcquireNotify/AcquiceWrite if the d-bus runs over tcp or the programming language doesn't support d-bus file descriptors? An ATT MTU property would be so much simpler and straight-forward. > except perhaps if the application requires something bellow the > default MTU bluetoothd but that can be a problem if other application > would start requiring their own MTU as well, so even if we introduce a > Property that would have to be read-only Yes! The idea was to have it read-only. It's sane to let the BT stack negotiate (a big value on non-embedded systems like Linux/BlueZ) immediately after the connection has been established. There should be no reason for an application using BlueZ to negotiate a smaller MTU than a "big" one, which BlueZ already selects. > but there may be races if the > application start writing/reading too fast or the remote end do > trigger its own exchange for some reason. It's already not possible to write anything after "Connected" has become true but before "ServicesResolved" becomes true (I get "org.bluez.Error.Failed: Not connected" in that case). I assume MTU is guaranteed to have been exchanged at this point, so there shouldn't be any problem for this case. Another possibility would also be to add a boolean "ATT MTU exchanged" property which is set to true when the MTU property becomes valid, if waiting for "ServicesResolved" wouldn't be enough. It should be fine also if the remote end sends an Exchange MTU request at the beginning of the connection since we can then immediately send a response and assign the MTU property without waiting for the Exchange MTU response (that corresponds to our request). In the case when the remote end sends a notification before it receives our Exchange MTU request, then the MTU property would correctly be 23 since the MTU Exchange hasn't finished yet. The list of five rules in Bluetooth Core specification Vol 3 Part F 3.4.2.2 (ATT_EXCHANGE_MTU_RSP) should also prevent most "race conditions". Let me know if you think I've missed some edge case... /Emil
