MSN Direct Services Architecture

10/16/2008

This topic describes the MSN Direct services architecture, which includes the primary architectural layers, how they interact with one another, and the different models for exchanging messages between the Windows Embedded NavReady powered device and the MSN Direct receiver.

Architecture Overview

• The following illustration shows the overall MSN Direct architecture:

The MSN Direct architecture includes the following three layers:

• Application Layer: The MSN Direct application runs in this layer on the Windows Embedded NavReady powered device. You must design this layer and make a subclass of the DBR701 class. In this layer, you must implement message-processing and message-handling code so that MSN Direct data can be displayed to the user.
• Library Layer: This layer primarily manages message transactions between the MSN Direct application and the MSN Direct receiver. The low-level details of the MSN Direct protocol are handled in this layer. The library layer supports both a push and pull model on the binary data cached at the receiver.
• Receiver Layer: This layer manages the receipt of messages from FM radio waves. This layer uses the .NET Micro Framework. It obtains data, caches it, decodes it, and sends it over the serial connection to the Windows Embedded NavReady powered device.

The architecture for exchanging messages among all three layers involves two models: the push model and the pull model.

Push Model Overview

When the MSN Direct receiver is operating in push mode, it sends new MSN Direct data to the host every 113 seconds.

Message Delivery Initiated by the Receiver

With the push model, the MSN Direct receiver pushes a message to the Windows Embedded NavReady powered device. The push model of exchanging messages is always initiated by the receiver.

1. Receive Data Pushed from the Receiver
   In the push model, the DBR701 class receives data from the receiver by handling the message. The DBR701 class manages the received bytes according to an internal state machine which is used to determine whether the item that is received is a handshake string or an incoming message. If it is an incoming message, the DBR701 instance formats the incoming bytes into a message object.
2. Process an Incoming Message
   When the message end-of-frame is received, the DBR701 instance calls the DBR701::ProcessInMessageFromReceiver method. This method in turn delegates the delivery of the message to one of the threads running specifically to handle message delivery. Then, one of these threads calls the virtual method ProcessInMessageFromReceiver, specifying a time-out period of 900 milliseconds. The default implementation of this method creates a simple response message that indicates success, and then returns this response message to the receiver. The application developer is expected to make a subclass of DBR701 and override the method ProcessInMessageFromReceiver and in it provide specialized functionality for each type of message received in the application layer. The MSNDirectApp sample provides sample message classes that directly map the internal members to the payload format on the serial communications protocol.
3. Send Response to Receiver
   After the incoming message is suitably processed, the application must create a response message that has an instance of GenericHostMsg. This will be sent to the receiver by the DBR701 class, therefore completing the transaction.
   However, the application must answer within the specified time-out period to comply with the 1 second time out configured in the protocol. This specified time-out period is 900 milliseconds. If an answer is not received within this time period, the library will automatically respond to the receiver with a response message that contains a time-out error. Any additional information returned later from the application is ignored.
   Notice that the thread remains busy during time that the application does not return from the callback. However, a different thread is used to handle all other incoming messages. This process continues for as long as there are available threads in the pool. The size of the pool is configurable at compile time by the application.

Pull Model Overview

With the pull model, the Windows Embedded NavReady powered device asks the MSN Direct receiver to send cached messages.

The pull model of exchanging messages can be initiated in two ways:

• Message delivery initiated by the DBR701 class
• Message delivery initiated by the application layer

Message Delivery Initiated by the DBR701 Class

When the pull model of exchanging messages is initiated by DBR701, messages are pulled from the receiver by the DBR701 class.

Message Delivery Initiated by the Application Layer

When the pull model of exchanging messages is initiated by the application layer, it means that one of the following is true:

• The application is requesting data from the receiver
• The application is sending a command to the receiver

1. Request data from the Receiver by calling data type specific methods
   When the pull model is initiated by the application, the application can call one of the methods provided in the DBR701 class to generate a host-initiated transaction for receiving data for a given data type. Then, the ProcessInMessageFromReceiver method will wait for the answer.
   The application can also call the DBR701::SendRequestSync method directly, by using a correctly formatted GenericHostMsg object to start the transaction.
2. Request specific data-type synchronization
   When you use one of the methods provided by the DBR701 class for starting a transaction, the DBR701 class automatically fills in the required fields in a GenericHostMsg instance, computes the corresponding Cyclic Redundancy Check (CRC) value, and then calls SendRequestSync to send the message to the receiver. If you choose to call the SendRequestSync method directly in your implementation rather than using the default functionality in the DBR701 class, you must implement these steps.
   Notice that SendRequestSync is also thread-safe and prevents more than one host-initiated transaction from executing at any time.
3. Receive requested response from the Receiver
   The receiver responds to the request within the time out period. The DBR701::ProcessInMessageFromReceiver method will be invoked when an answer becomes available.

See Also

Concepts

MSN Direct Services Overview

Other Resources

MSN Direct Services