Hi Emil, On Wed, Mar 4, 2020 at 2:41 PM Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote: > > Hi Luiz, > > Den ons 4 mars 2020 kl 20:44 skrev Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx>: > > > > It completely transparent to D-Bus, so if we do expose the MTU it > > > > should probably be reporting the biggest MTU of all connected channel, > > > > > > Is there ever any reason for one application to have more than one ATT > > > bearer? I thought the idea of EATT was to allow one ATT bearer per > > > application. > > > > EATT is meant to allow multiple outstanding requests, it probably > > would not escale if we would add an API to have a bearer per > > application so we just use the extra bearers as a pool. > > I just read the 5.2 overview and 5.2 specification again and I see now > that the overview suggests that a pool of bearers should be used, as > you mentioned. So yes in that case the maximum ATT_MTU of the bearers > seems reasonable to report (if they for some reason would differ). But > by having a pool like this, I hope implementations will make sure that > multiple Write Without Response values or notifications from the same > application are sent on a single bearer, to avoid reorderings. Commands don't need a response so in theory one should just use the unenhanced bearer or the first one EATT bearer regardless, in the current implementation I just pick the first bearer that allow sending all the data in one shot given that the MTU can be different. -- Luiz Augusto von Dentz
