On Fri, 11 May 2012, Gustavo Padovan wrote:
* 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.
This doesn't have anything to do with ACL fragments. When the timeout
expires, you're sending an L2CAP frame that will get passed up to the
remote profile right away. The remote L2CAP protocol will not wait
for any more data before passing the frame up to the profile, because
L2CAP doesn't know any more data is coming.
I'm following the TCP behaviour with MSG_MORE here.
TCP is a stream, like RFCOMM. UDP and L2CAP are based on datagrams.
The 200ms timeout makes sense for a stream, because message boundaries
have no meaning in a stream like TCP. Splitting up an L2CAP PDU like
this breaks all kinds of profiles that depend on message boundaries.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
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
