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. -- 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
