Hi Szymon, Lukasz, On Thu, Mar 10, 2016 at 12:26 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Szymon, > > On Thu, Mar 10, 2016 at 11:42 AM, Szymon Janc <ext.szymon.janc@xxxxxxxxx> wrote: >> Hi Luiz, >> >> On Thursday 10 of March 2016 11:35:23 Luiz Augusto von Dentz wrote: >>> Hi Lukasz, >>> >>> On Thu, Mar 10, 2016 at 11:17 AM, Łukasz Rymanowski >>> >>> <lukasz.rymanowski@xxxxxxxxxxx> wrote: >>> >> 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. Im actually abandoning this one as it seems Androind 5.1 and later seems to have this fixed. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
