GREETINGS AND SALUTATIONS!

Salutation on IrDA

 

 

 

Salutation may be implemented on IrDA through the Windows Socket interface. The following describes this technique.

Relationship of Software

Figure 4 shows the relationship of the Salutation Manager with the IrDA Stack and associated applications. This diagram is identical for both client and server implementations. The Salutation Manager, equipped with a transport manager specific to the IrDA protocol stack, is accessed by the application through the Salutation API. The Salutation Manager sends and receives Salutation Protocol over IrDA through the Windows Socket interface. The following sections will describe the interchange between these components.

Figure 4: Relationship of Salutation Manager to the IrDA Protocol Stack using unique Transport Manager

Initialization

When each Salutation Manager is initialized, it starts the IrDA Transport Manager. The Transport Manager calls the IRSocket �socket()�EAPI to build an IR socket. Through the sockets interface, the Transport Manager on the server binds to the socket, sets the IrDA transceiver in listen mode and sets the transceiver to accept any inbound transmissions.

Salutation Manager ID Exchange

The Transport Manager on the client and service devices performs the function of searching for other devices and determining if these devices are Salutation-enabled.

Using the SetSocketOpt(IAS_SET) call, the service�s Transport Manager sets a Salutation Manager Identifier (SLM-ID) in the IAS registry of the IrDA stack. The IAS_SET structure values are set as follows:

    irdaClassName = "SLM"

                irdaAttribName = "SLM-ID"

                irdaAttribType = 0x00000001

                irdaAttribute.irdaAttribInt = an integer specifying an SLM-ID unique to the device

The Salutation Architecture Specification defines the SLM-ID for IrDA as the "IrLAP device address (4 octets), followed by a random value through the 16th octet". Although the IrLAP device address is not universally unique, the SLM-ID should be unique in practice considering the mobile nature of the IrDA protocol and the sufficiently long (11 octets) random value.

The client's Transport Manager searches for other devices using the command loop:

            GetSocketOpt(IRLMP_ENUMDEVICES)

When successful, the GetSocketOpt command returns a list of responding devices. The client device's Transport Manager then uses a GetSockOpt(IAS_QUERY) to determine if the found devices are Salutation enabled. If they are Salutation enabled it also discovers the values of their SLM-IDs.

The client�s Transport Manager builds a correlation table between the SLM-ID and the .irdaDeviceID. The client�s Transport Manager is responsible for converting requests to a SLM_ID specific to a .irdaDeviceID.

Finally, the Transport Manager issues a IRSockets connect() command to each of the found Salutation-enabled devices. This causes a new socket handle to be generated on each of the service devices, which in turn establishes an IrDA link between the client and one or more service devices. The Transport Managers maintain this link.

Capability Search

The rest of the interactions between devices take place through the Salutation Manager via the Salutation APIs

To establish the capabilities of Functional Units contained on the device, a service application uses the slmRegisterCapabilities() call. The service�s Salutation Manager holds this information and compares it to requests for service received over the IrDA interface.

Client applications use the slmSearchCapabilities() call to determine the SLM-ID of devices meeting the search criteria defined by the application. Search criteria are specified through one or more Functional Unit Description Records contained in the slmSearchCapabilities() call. The client Salutation Manager packages this request into a QUERY_CAPABILITIES Salutation Protocol command and sends it, via an IRSockets send() command, to all identified Salutation-enabled devices.

Each receiving device compares the attributes of the received Functional Unit Description Record(s) with the Functional Unit descriptions registered there. This comparison is performed via an algorithm specified in the Salutation Architecture Specification. If there is a positive compare, the service Salutation Manager packages its response in a QUERY_RESPONSE Salutation Protocol response and sends this to the client device in an IRSockets send() command. Using the correlation table, the client Transport Manager maps the positive response to an SLM-ID which is returned to the application in response to the slmSearchCapabilities() call, and passes the resulting information through the Salutation manager to the client.

Capability Query

Client applications use the slmQueryCapabilities() call to determine the specific capabilities of one of the service devices. The client specifies which device by specifying an SLM-ID. Search criteria are again specified through one or more Functional Unit Description Records contained in the slmQueryCapabilities() call. The client Salutation Manager packages this request into a QUERY_CAPABILITIES Salutation Protocol command. The client�s Transport Manager correlates the SLM-ID to the irdaDeviceID and sends the QUERY_CAPABILITIES command, using an IRSockets send() command, to the specified device.

The receiving device compares the attributes of the received Functional Unit Description Record(s) with the Functional Unit descriptions registered there. This comparison is performed via an algorithm specified in the Salutation Architecture Specification. If there is a positive compare, the service�s Salutation Manager packages its response in a QUERY_RESPONSE Salutation Protocol response and sends this to the client device in an IRSockets send() command. This information is passed through the client�s Salutation Manager and is returned to the client.

Data Exchange

When the client has located the service it requires, it may exchange other data through the IRSockets send() and receive() commands. When the communication is complete, the client application calls the IRSockets closeSocket() command.

The service application may use an slmUnregisterCapabilities Salutation Manager call to make a function unavailable to other devices.

Extensions

In the preceding example, the Salutation Architecture has been used on IrDA through the use of WinSockets. Similar techniques can be demonstrated using other Sockets interface to other protocols.

Watch for an application note that discusses the Salutation Service Discovery Protocol on IrDA to be posted in the coming weeks on the Salutation web site www.salutation.org.