Hi Tim, Marcel,
>> +enum obex_transport_format{
>> + OBEX_MT_STREAM ,
>> + OBEX_MT_SEQPACKET
>> +};
>> +
>> And more important, I have no idea why are you doing this anyway. Even
>> with L2CAP this should run over SOCK_STREAM.
>
>Is that really so? I expect exposing L2CAP ERTM as a stream could break protocols above that >expect datagram-boundary preservation (eg RTP). Or can break protocols that mandate that >only one higher-layer packet exists in each L2CAP SDU. For these the socket needs to be >packet based.
>
>So, my surprise is that ERTM is exposed as SOCK_STREAM. So I do have an idea why the patch >mentions sequenced packet...
>
>> I assumed that OPP and FTP over L2CAP are requiring eL2CAP actually
>> which is re-presented as a stream.
>
>Yes, OBEX over L2CAP requires enhanced retransmission mode.
>From the Core Specification, Vol. 3, Part A, Pt. 7.3 Encapsulation of SDUs:
"It is assumed that SDU boundaries shall be preserved between peer upper layer entities."
SDU is by definition an abstraction exposed to the upper layer. This assumption permeates all of Bluetooth and breaking it can have dire consequences both for profiles assuming their messages map 1:1 to SDUs.
Cheers,
Piotr
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
