Discovery protocol SDP - universAAL/middleware GitHub Wiki

• Define the role of the protocol

SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary). SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order. SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given instant. In other words, a client must receive a response to each request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.

• Define significant scenarios where the protocol is actually involved
• Provide and overview of protocol architecture (free to organize this section in according to the available info sources: wikipedia, rfc, official specs)
• Quick protocol stack snippet by providing a concise description of every layer

The bluetooth protocol stack is split in two parts: a "controller stack" containing the timing critical radio interface, and a "host stack" dealing with high level data. The controller stack is generally implemented in a low cost silicon device containing the bluetooth radio and a microprocessor. The host stack is generally implemented as part of an operating system, or as an installable package on top of an operating system. For integrated devices such as bluetooth headsets, the host stack and controller stack can be run on the same microprocessor to reduce mass production costs; this is known as a hostless system.

• Define existing device constraints for protocol adoption: general purpose device vs specific one. This section aims at quickly mark those protocols designed for unrealistic AAL Node

• Define how the selected protocol answers to node addressing challenge
• Try to provide the ad-hoc definition of “node-addressing” for the specific protocol. (Maybe there exist different definitions of “addressing” for the reviewed protocols)
• Provide examples and simple scenarios where the addressing features are involved
• Define well-know limitations and possible draw-backs in protocol adoption

• Define and describe available (OS) protocol implementations