headset/sco support in freebsd

[Maksim Yevmenkin]

Iain,

 >> i have not committed it yet. there is also a bluetooth sco sockets
 >> layer to simplify programming api.
 >
 > Max, I am working on this now for NetBSD - I had it in mind to use
 > SOCK_STREAM type with 'HCI' protocol for this but I notice that BlueZ
 > have declared a BTPROTO_SCO and are using SOCK_SEQPACKET instead.
 >
 > My feeling is that I am going with SOCK_STREAM since its clearly a
 > stream of data, do you have an opinion?

well, yes and no. "yes" because sco primary goal is to carry audio/video 
streams. "no" is because of bluetooth specific.

SOCK_STREAM "... provides sequenced, reliable, two-way, connection-based 
byte streams ..."

SOCK_DGRAM "... datagrams (connectionless, unreliable mes­sages of a 
fixed maximum length) ..."

SOCK_SEQPACKET "... provides a sequenced, reliable, two-way connection 
based data transmission path for datagrams of fixed maximum length; a 
consumer is required to read an entire packet with each read system call 
..."

please keep in mind that sco is not really a protocol. it is more of a 
transport. sco has fixed packet length. sco is not reliable. the way i 
understand it, sco packets cannot be re-ordered but can be dropped.

imo, none of the SOCK_xxx types describes sco exactly. to me its either 
SOCK_DGRAM/SOCK_SEQPACKET (more preferred) or SOCK_STREAM (less preferred).

in my code, i opted for SOCK_SEQPACKET (just like linux) to describe 
properties of sco "protocol/transport". i guess, it is up to the one who 
implements sco sockets to choose if SOCK_xxx type describes "protocol" 
properties or what "protocol" can be used for.

in other words sco "protocol" has (some) SOCK_SEQPACKET properties vs. 
sco "protocol" is/can be used to transfer SOCK_STREAM type of data.

thanks,
max