Registering and Deregistering the Extension Layer (Windows CE 5.0)
You can use functions that enable the extension layer to connect and disconnect from the protocol stack.
Note The terms LAYER_ and layer_ are generic placeholders and are used in this section instead of real stack layer prefixes such as HCI_, L2CAP_, SDP_, RFCOMM_, hci_, l2cap_, sdp_, rfcomm_ prefixes that are part of real names.
Register the extension layer with the layer it extends, by calling Layer_EstablishDeviceContext.
When the extension layer makes a call to Layer_EstablishDeviceContext, it must pass pointers to LAYER_EVENT_INDICATION and LAYER_CALLBACKS. In addition, it must receive a pointer to LAYER_INTERFACE.
The following code example shows the Layer_EstablishDeviceContext function signature.
int Layer_EstablishDeviceConnect(
void* pUserContext, /*IN*/
//Layer specific filtering parameters /*IN*/
...
LAYER_EVENT_INDICATION* pInd, /*IN*/
LAYER_CALLBACKS* pCall, /*IN*/
LAYER_INTERFACE* pInt, /*OUT*/
int* pcDataHeaders, /*OUT*/
int* pcDataTrailers, /*OUT*/
HANDLE* phDeviceContext /*OUT*/
);
The *pcDataHfeaders and *pcDataTrailers parameters are used to indicate how many bytes the extension layer must pre-allocate for extended-layer headers in the packet.
Layer_EstablishDeviceContext accepts layer specific filtering parameters, to filter incoming connections. This parameter is different for different layers and its value does not intersect for multiple clients of the same layer. For example, in RFCOMM_EstablishDeviceContext, the filtering parameter is channel. Passing a non-zero value to channel enables RFCOMM clients to listen only on the specified channel.
Note One and only one general-purpose stack (channel=0) can be installed. Multiple stacks can accept connections based on some parameter, such as address or connection type.
Another example of a filtering parameter is psm that specifies the Protocol/Service Multiplexer (PSM). Every stack maintains one and only one general client that accepts all incoming connections. For example, for L2CAP, PSM is set to zero (0) to listen to all the incoming connections.
Only the connection-oriented L2CAP channels are implemented. CLT-related functions are stubbed with NULL values. L2CAP accepts all negotiation parameters, but passes it to the user without attempting to enforce or even store it. For more information, see Bluetooth Stack Implementation Considerations and the Bt_ddi.h file for complete specifications of the L2CAP interface.
Alternatively, a layer can restrict incoming connections. For example, RFCOMM restricts connections to ones received on PSM 3. RFCOMM passes negotiated parameters to the top level of the stack, but neither enforces nor stores them.
The same is true for model commands and statuses that are used by a port emulation entity. RFCOMM uses RFCOMM_StackEvent to pass flow control status to every client. It also enforces aggregate, but not connection-based flow control. For complete specifications of the RFCOMM interface, see the Bt_ddi.h file.
Note SDP restricts connections to ones those received on PSM 1, and the SCO stack restricts connections to all incoming SCO connections.
Each incoming connection is checked to match restrictions against existing clients with connection restrictions. If no matching client exists, the generic upper-layer handler is executed.
When the extension layer is ready to shutdown, call the Layer_CloseDeviceContext function. All calls that were placed by the extension layer are terminated and the connections, owned by the layer, are closed.
The following code example shows how to declare the Layer_CloseDeviceContext function.
int Layer_CloseDeviceContext ( HANDLE hDeviceContext );
See Also
Creating a Bluetooth Stack Extension Layer | Bluetooth OS Design Development | Host Controller Interface
Send Feedback on this topic to the authors