Re: [Bluez-devel] Regarding a2recv

["Henryk Plötz" <henryk@ploetzli.ch>]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

Moin,

Am Sun, 08 May 2005 22:29:40 -0600 schrieb Brad Midgley:

> The only tricky part is the MAX_ADDITIONAL_CODEC stuff. Make sure we 
> only try to send one codec when we're reporting our sink's
> capabilities  and accept multiple codecs when we're reading
> capabilities.

Ugh, yes. It would be possible to simple address infos[] beyond the
borders that are set by 1 + MAX_ADDITIONAL_CODEC if it is made sure that
there is that much space assigned. (If I recall correctly that's a
common technique to get varying length fields in structs.) However, from
the header it is not clear how many capabilities there will be, which is
something I don't like. We would have to resort to an all-zero seid_info
or something like that to denote the end of the packet (the read
function must than insert that, and the write function would have to
send up to that border).

> Maybe what you're proposing will clean up the "optional" error codes
> in places like open_stream_rsp. The header would look different so
> you could distinguish the error codes and compute the size properly
> when sending. 

That was exactly the idea.

> Be sure we accept the extended size with the error codes when
> receiving.

I'm not accustomed to bluetooth socket programming but I guess what I'm
doing currently (simply read() up to a maximum (mtu?) size, check the
returned size and optionally the header and cast the buffer to our
struct) is fine for that purpose.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]