- From: Luiz Augusto von Dentz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Sep 2016 12:15:32 +0000
- To: public-web-bluetooth-log@w3.org
BlueZ actually attempts to do the maximum possible, our default per channel is actually 672 bytes given that comes from L2CAP, so in fact it can be over 512 bytes but usually the peripheral limits the MTU. As for exposing an API to set the MTU this is quite tricky because of the following: 1. The MTU shall only be negotiated once, so we might have to fail if that was already done previously. 2. MTU needs to be symmetric for input and output so it might be forced to be lower than the value required. 3. Usually the MTU is used to define application level fragmentation, stream/firmware transfers, etc. These are not very nice to be done over D-Bus and instead perhaps should done over e.g. a pipe passing a fd to the application where one can get the MTU of the connection and perhaps even lock the attribute so it is only accessed by that application using the fd. Note this type of application is abusing the ATT/GATT stack since the attributes were never meant to be used as stream endpoints, instead L2CAP Channels should have been used but it seems most OSes never implemented support for them leading to the current situation. -- GitHub Notification of comment by Vudentz Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/284#issuecomment-244733065 using your GitHub account
Received on Monday, 5 September 2016 12:16:17 UTC