From 5a2d6700203383d2c0bc45974dda45f23c4e31dc Mon Sep 17 00:00:00 2001 From: "matthias.ringwald" Date: Sun, 13 Jun 2010 15:46:31 +0000 Subject: [PATCH] updated TODO and added SDP log --- SDP.txt | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TODO.txt | 60 ++++++++++++++++++++--------------------- 2 files changed, 111 insertions(+), 31 deletions(-) create mode 100644 SDP.txt diff --git a/SDP.txt b/SDP.txt new file mode 100644 index 000000000..09e88ecdb --- /dev/null +++ b/SDP.txt @@ -0,0 +1,82 @@ +SDP for BTstack + +General: + * Protocol: request/response, half-duplex + * Endianess = BIG/Network! not little endian as usual + * Server maintains a list of service records + * service (record) is instance of a service class + * a service record = list of service attributes + * service attribute = { attribute ID, attribute value } + * service record handle: 32 bit number (used internally) + * service record handle + * 0x00000000 used for SDP server, + * 0x00000001-0x0000FFFF reserved + * attribute ID: 16 bit (pre-defined), data element + * attribute value: var length field, data element + * service class: UUID (128 bit) stored as ServiceClassIDList attribute + * service classes form an inheritance tree, which each subclass specifying more attributes + * Bluetooth Base UUID: 00000000-0000-1000-8000- 00805F9B34FB + * 16 bit UUID => Bluetooth Base UUID + 16_bit_value * 2^96 + * 32 bit UUID => Bluetooth Base UUID + 32_bit_value * 2^96 + * Service Search Pattern: list of UUIDs required in a service record to be present for a match + * Browse Group UUID: all top-level services contain browse group UUID in the BrowseGroupList attribute + * Service Browsing Hierarchy is possible - not supported by BTstack for now + * Data representation: like XML + * PDU: PDU ID(1), Transaction ID(2), Param length(2), params* + * ServiceSearchRequest/ServiceSearchResponse: list of UUIDs to be matched by service record -> list of service record handles + * ServiceAttributeRequest/ServiceAttributeResponse: get list of attributes for a given service record handle + * Service SearchAttributeRequest/SearchAtrributeResponse: for all service records that match ServiceSearchPattern: return list of attributes that match AttributeIDList + * Transaction ID of response = ID of request + * param lengh in bytes + * Continuation state parameter: send to client to denote further data (max 16 bytes) + * To get RFCOMM channel, we use SDP_ServiceSearchAttributeRequest(RFCOMM service, RFCOMM type) + +Implementation: + * DataElement creation API - no extra memory + * helper functions: + * attribute ID in AttributeIDList + * get attributes specified by AttributeIDList + * service record contains UUID + * does service search pattern matches record + * get attribute value (DE) for attribute ID + * create service record handle (incl. ServiceRecordHandle management) + * visitor pattern for DES traversal + * call handler on every element: int handle_element(uint8_t element, void *context) - done? + * Dispatch packets for protocols implemented by BTdaemon + * add packet_handler to l2cap_service_t and l2cap_channel_t + * pass acl/event handler to l2cap_register_service_internal + * copy acl/event handler to l2cap_channel_t + * if specified, call custom packet_handler instead of general one + * acl -> l2cap -> l2cap_channel -> acl/event handler OR daemon + * LinkedList of service records + * alloc { linked_list_item_t ; ServiceRecord } + * add service record: service record -> service record handle or 0 + * remove service record: service record handle (32bit) + * SDP as part of stack itself + * Register SDP PSM=0x0001 + * Accept incoming connections + * Define all SDP requests/response PDU-IDs + * Handle all three SDP requests by denying + * ServiceSearchRequest + * ServiceAttributeRequest + * ServiceSearchAttributeRequest + * Dynamically create denial + * Handle ServiceSearchAttributeRequest + * Handle ServiceSearchRequest + * Handle ServiceAttributeRequest + * Extract sdp_create_error_response + * call sdp_create_error_response when service record handle is invalid + * Define and implement client commands & events for SDP registry + * Store client connection in service record item + * Unregister service when client disconnects + * Send SDP_ErrorResponse for invalid records + * Implement Continuation: limited nr of ServiceRecordHandles or AttributeList(s)ByteCount + * ServiceSearchRequest: Iterate over all records - use record index as cont. + * ServiceAttributeRequest: Iterate over all attributes - use attribute index as cont. + * ServiceSearchAttributeRequest: Iterate over all records and attributes. Use {record, attribute} index + * Test continuation for all three commands + * add 2 records, get all data back with limited result size + * sdp_handle_service_search_attribute_request + + * Why do I don't get any services using sdptool "sdptool get --raw --bdaddr 00:80:37:16:a2:52 0x10001" ? + * ServiceSearchAttributeRequest public browse group 0x0000-0xffff diff --git a/TODO.txt b/TODO.txt index 7c4b6a893..4f50b34ea 100644 --- a/TODO.txt +++ b/TODO.txt @@ -3,34 +3,17 @@ 2009-11-08: Release 0.1 NEXT: -- suport multiple signaling commands in single ACL packet - - have l2cap_primary_signaling_handler use offsets relative to start of commands (byte 8) instead of start of packet - - call l2cap_primary_signaling_handler for each command +- implement SDP +- test SDP implementation against Mac/Linux Service Discovery + +== Release Version 0.2 +- move RFCOMM code into BTdaemon - add extern "C" to bstack methods - see: http://stackoverflow.com/questions/376966/using-c-c-static-libraries-from-iphone-objectivec-apps -- clean up control flow - - l2cap directly sends data over socket: good/bad? - - split daemon into stack parts - - should there be STACK API/interface? -- BUG: bt_close crashes when used in CocoaTouch app -- Provide BTstackManager Objective-C class - - move connection methods to BTdevice (get more object oriented) - - initWithAddress:(bd_addr_t *)addr - - setters private - - implement l2cap code - - implement rfcomm code - - animate discovery dialog: - * use indexPathsForVisibleRows and cellForRowAtIndexPath: when you want to refresh just the cells that are on the screen - * use insertRowsAtIndexPaths:withRowAnimation: to add rows - * use deleteRowsAtIndexPaths:withRowAnimation: to remove them- - figure out how to receive iPhone System Power IONotifications (in BTdaemon) to detect, when phone gets locked - - some trick - - use Cocoa run loop for background app? -- move RFCOMM code into BTdaemon - add timeouts to cocoa run loop - L2CAP - segmentation - - extend SpringBoard feedback - show alerts/messages using SpringBoardAcccess, e.g. Bluetooth disconnected by remote device - add code to notify about remote disconnets @@ -46,13 +29,32 @@ NEXT: - flow control - add configure option for uart flowcontrol - create +- Bluetooth low-power modes useful -== Release Version 0.3 -- implement RFCOMM server -- implement SDP -- implement PAN +== USB Support == +- Store array of data sources to be able to remove them on usb_close -== Release Version 0.4 +== Objective-C Interface == +- move connection methods to BTdevice (get more object oriented) + - initWithAddress:(bd_addr_t *)addr + - setters private +- implement l2cap code +- implement rfcomm code +- animate discovery dialog: + * use indexPathsForVisibleRows and cellForRowAtIndexPath: when you want to refresh just the cells that are on the screen + * use insertRowsAtIndexPaths:withRowAnimation: to add rows + * use deleteRowsAtIndexPaths:withRowAnimation: to remove them- + +== Refactor/Improve Architecture == +- use single standard packet handler for acl & events + - hci_transport -> hci + - hci -> l2cap + - l2cap -> daemon +- add linked_list_iterator that can remove elements (used by l2cap_close_connection and sdp_unregister_services_for_connection +- clean up control flow + - l2cap directly sends data over socket: good/bad? + - split daemon into stack parts + - should there be STACK API/interface? - unify packet generation - btstack events - cmd packets @@ -60,7 +62,3 @@ NEXT: - auto-generate code for sending commands from structured text input file - devise concept for access to event data - auto-generate event struct getter? STRUCTURE_get_FIELD -- Bluetooth low-power modes useful - -== USB Support == -- Store array of data sources to be able to remove them on usb_close \ No newline at end of file