Re: [PATCH BlueZ 2/2] core/device: Don't set MTU when acting as a peripheral

Hi Szymon,

On Thu, Mar 10, 2016 at 11:42 AM, Szymon Janc [off-list ref] wrote:

Hi Luiz,

On Thursday 10 of March 2016 11:35:23 Luiz Augusto von Dentz wrote:

quoted

Hi Lukasz,

On Thu, Mar 10, 2016 at 11:17 AM, Łukasz Rymanowski

[off-list ref] wrote:

quoted

quoted

Not only we cannot be configured as server, but even if we do the
roles are only relevant for PTS because otherwise there is no way to
tell the roles of the remote device.

If device sends request that means it is a Client. If not that means
it is a Server.

Well if it send it can be a Client/Server as well, btw some systems
including Android appear to have support to send Exchange MTU at any
point so detecting a server only pretty hard, besides our current
design split Server and Client functionality so waiting to see if
anything has been received before starting sending anything is not so
trivial and we had still to choose an arbitrary timeout to wait for
detecting the role but if both are based on BlueZ this would just
delay each other.

Maybe we could simply delay MTU exchange until we are done with discovery?
For discovery we shouldn't need larger MTU. And if in the meantime remote
initiates MTU exchange we can skip MTU exchange from our side.

Actually discovery is where it makes most of the difference for
devices with big databases which delays quite a lot the first
connection (sometimes more than 10 seconds to discover everything). We
do have a cache to mitigate that in the subsequent connections, but I
wouldn't like to receive complains again that discovery takes too long
because the MTU was not changed.

-- 
Luiz Augusto von Dentz