linux: add MTU accessor #379
Conversation
|
I will try that PR and see if that works for me. I think I can settle for a micro-fork till a similar functionality lands upstream |
| // MTU returns the exchanged MTU value, or zero if not available. | ||
| func (c *Characteristic) MTU() int { | ||
| return c.char.mtu | ||
| } |
There was a problem hiding this comment.
The MTU is, as far as I know, the property of a connection. A characteristic is local, and can be read/written from multiple connected devices. So it doesn't make much sense to expose it as part of Characteristic.
A better place would be bluetooth.Device (though I'm not sure BlueZ exposes the MTU like that).
There was a problem hiding this comment.
It doesn't look like BlueZ exposes the MTU on the device: https://man.archlinux.org/man/extra/bluez-utils/org.bluez.Device.5.en
By looking around in the BlueZ source, the two ways that the MTU is exposed are:
- Via the
MTUproperty on the characteristic here - Via the
mtuoption passed toReadValueandWriteValuehere
By digging a little bit more it seems that the MTU property is the "Biggest possible MTU" and is updated whenever a new ATT channel is added so that it only grows. However, the mtu option seems to reflect the actual MTU of the connection.
Now, the reason I originally added this was to be able to maximize the size of writes, even when multiple devices are connected. It seems to me that doing writes with the MTU property will leave out devices that have a lower MTU. To me it seems the correct thing to do is keep the minimum MTU value and write using that. However, if any device re-negotiates its MTU we are stuck with the old one.
Does this make sense?
There was a problem hiding this comment.
So, what you're saying is the BlueZ doesn't expose the minimum MTU size at all? (Since it only grows, there can be devices connected with a smaller MTU than is reported).
There was a problem hiding this comment.
Yes, that's what I think, but I shall report back once I tested it.
This PR exposes the MTU by reading it from the options of
ReadValueandWriteValue. The downside of this approach is that there's no way to know the MTU if no reads and no writes have been made, but one could argue that it's not needed then. The D-Bus API doesn't seem to provide other ways to get the MTU anyways.