Re: Queued Writes vs. MTU
Re: Queued Writes vs. MTU
- Subject: Re: Queued Writes vs. MTU
- From: Matthias Ringwald via Bluetooth-dev <email@hidden>
- Date: Fri, 4 Nov 2022 13:44:13 +0100
Hi Mickey
As for the maximal length, that's a good question. In the Bluetooth Spec, I can
find.
ATT, 3.29. Long Attributes:
"... It is not possible to determine if an attribute value is longer than
(ATT_MTU-3) octets using this protocol.
A higher layer specification will state that a given attribute can have a
maximum length larger than (ATT_MTU-3) octets.
The maximum length of an attribute value shall be 512 octets...."
So, there's no way in ATT to query an attribute length. On the other hand, it
might work if the peripheral supports Queued Writes.
I would agree that the documentation could be improved to explain that the
value for WriteWithoutResponse returns a best effort by the OS, but that it
might not work. :)
Best
Matthias
> On 4 Nov 2022, at 13:32, Michael Lauer <email@hidden> wrote:
>
> I see and will do that, thanks.
>
> For the records though, do we agree
> that unconditionally returning 512 for WriteWithResponse is an iOS bug?
>
> Best,
>
> :M:
>
>> On 3. Nov 2022, at 17:29, Matthias Ringwald <email@hidden>
>> wrote:
>>
>> Hi Mikey
>>
>> According to the log, the ATT MTU is 247, which you also get back from
>> CBPeripheral: maximumWriteValueLength for Write Without Response. So, that's
>> correct.
>> It looks like CoreBluetooth sends data shorter then the ATT MTU as write
>> without response (write command), and uses prepared writes for longer ones.
>>
>> I guess if you chunk your data based on the maximumWriteValueLength for
>> write without response, you should be good.
>>
>> Best
>> Matthias
>>
>>> On 2 Nov 2022, at 14:34, Dr. Michael 'Mickey' Lauer <email@hidden>
>>> wrote:
>>>
>>> Hi Matthias,
>>>
>>>> Is there are reason for write commands longer than 247 bytes? The
>>>> over-the-air packets cannot be bigger anyway, so there's not much
>>>> throughput improvement.
>>>
>>> I see. Well, I just want to maximize bandwidth. The commands I’m sending to
>>> the device are max. 8K and I though the less fragmentation on the transport
>>> layer the better.
>>>
>>>>
>>>> Could you post a PacketLogger trace to check the ATT PDUs?
>>>
>>> Please find the trace attached. Note that the problematic device is
>>> 48:23:35:00:B5:A4 and from the App-perspective I’m sending my first long
>>> command (512 bytes of data) @ Oct 25, 15:26:11.676 when the transfer
>>> suddenly
>>> stalls.
>>>
>>>> How did you get the max write size? CBPeripheral:maximumWriteValueLength
>>>> with both write types?
>>>
>>> Correct.
>>>
>>> Best regards,
>>>
>>> Mickey.
>>>
>>> <obdlink-cx-512-loss.pklg>
>>>>> On 28 Oct 2022, at 15:42, Dr. Michael 'Mickey' Lauer via Bluetooth-dev
>>>>> <email@hidden> wrote:
>>>>>
>>>>> I have a problem with a BLE peripheral and iOS.
>>>>> It’s unclear who is to blame, but one (or both) are doing something bogus.
>>>>>
>>>>> Let’s assume I only want to do WriteWithResponse in order to have
>>>>> better diagnostics (delegate being called after transmit).
>>>>>
>>>>> When I ask iOS for the WriteWithResponse MTU, it returns 512.
>>>>> Sending packets up to 247 data bytes works fine (which, by the way, is
>>>>> what iOS reports for WriteWithoutResponse), but once I
>>>>> exceed this, iOS sends a PREPARE WRITE to my peripheral, which –
>>>>> due to that peripheral not implementing queued writes – is not answered
>>>>> and the whole transfer stalls.
>>>>>
>>>>> Unfortunately it is an off-the-shelf BLE device (OBDLink CX OBD2 adapter),
>>>>> where I don’t have any control over the stack it’s using.
>>>>>
>>>>> Could anyone share some light on this? Let’s start by the question
>>>>> why iOS claims 512 to be an OK MTU for that peripheral?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Mickey.
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Bluetooth-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden