* Mat Martineau <mathewm@xxxxxxxxxxxxxx> [2012-05-11 11:38:15 -0700]: > > On Fri, 11 May 2012, Gustavo Padovan wrote: > > >There is now a 200 milliseconds limit for which L2CAP will wait for > >which L2CAP will wait before send the already queued data to the > >controller. > > > >Signed-off-by: Gustavo Padovan <gustavo@xxxxxxxxxxx> > > A timeout like this makes sense with a streaming protocol, but not > with a datagram protocol like L2CAP. The application could be > waiting on file I/O (especially on a flash filesystem), be waiting > for another blocking call to return, or another resource-intensive > application could be hogging the processor for a short time. If an > incomplete SDU gets sent out because of a timeout like this, the > profile on the other side will see it as corrupt. Better to keep > the queued data indefinitely. I don't think this would case problems, before this gets to the profile the ACL frame needs to be built and it won't be until we get the all pieces of the L2CAP frame. I'm following the TCP behaviour with MSG_MORE here. Gustavo -- 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
