3.2.5 Processing Events and Sequencing Rules
The server receives messages from the client, sent through the back-channel. These messages fall into three categories: response messages, informational notifications, and critical notifications.
Response messages are sent by the client only when the server sends a corresponding request message. For example, if the server sends a MILCMD_TRANSPORT_SYNCFLUSH message to the client, then the client MUST reply with a MILMSG_SYNCFLUSHREPLY message. The client MUST NOT send response messages unless a request message is received. The following messages are response messages:
MILMSG_SYNCFLUSHREPLY: A channel message sent in response to MILCMD_TRANSPORT_SYNCFLUSH. This message MUST be sent after all messages preceding the MILCMD_TRANSPORT_SYNCFLUSH message have been executed.
MILMSG_CAPTUREBITSREPLY: A channel message sent in response to MILCMD_TARGET_CAPTUREBITS. This message MUST be sent after all messages submitted before the request have been completed.
MILMSG_METARTCAPTUREBITSREPLY: A channel message sent in response to MILCMD_METABITMAPRENDERTARGET_CAPTUREBITS.
MILMSG_VERSIONREPLY: A connection-level message sent in response to MILCTRLCMD_VERSIONREQUEST.
MILMSG_NOTIFYROUNDTRIPREPLY: Sent in response to MILCMD_TRANSPORT_ROUNDTRIPREQUEST. This message MUST be sent after all preceding messages are completed.
MILMSG_ASYNCFLUSHREPLY: Sent in response to a MILCMD_TRANSPORT_ASYNCFLUSH message.
Informational notifications are issued autonomously by the client to inform the server of state changes. The server MAY safely ignore these messages, or it MAY use them to modify the data it sends to the client. For example, in response to the MILMSG_HARDWARETIER message, the server can either degrade or enhance the complexity of the graphical data it sends to the client so as to match the reported changing hardware capabilities. The following messages are informational notifications:
MILMSG_HARDWARETIER
The MILMSG_HARDWARETIER message is sent in two different situations:
MILMSG_HARDWARETIER MUST be sent as a response to an explicit request, indicated by the server with the MILCMD_CHANNEL_REQUESTTIER message.
The client MAY send this message after a display modification. In this case, the message is issued by the client to any channel on which a MILCMD_PARTITION_REGISTERFORNOTIFICATIONS message has been sent.
A display modification can, for example, include any combination of the following: mode change, monitor topology change, resolution change, color depth change, or driver update.
Critical notifications are also issued autonomously by the client, but the server MUST process these messages in specific ways. The following messages are critical notifications:
MILMSG_COMPOSITIONDEVICESTATECHANGE: Issued by the client if the composed desktop state changes while the current scene is being rendered. The valid device states are enumerated by MilCompositionDeviceState. In response to this message, the server MAY re-build mil resources attached to composed desktop resources that could have become invalid.
MILMSG_PARTITIONISZOMBIE: Sent by the client whenever it encounters an error during protocol parsing or scene rendering. The server will respond by shutting down all channels and connections, and then rebuilding the rendering scene.
MILMSG_RENDERSTATUS: Sent by the client to indicate that the status of the composition engine has changed. This notification MUST be sent when the client experiences a non-fatal asynchronous rendering failure.
MILMSG_DISABLECOMPOSITION: Sent by the client to indicate that desktop composition has been disabled. In response to this message, the server shuts down all channels and connections.
MILMSG_CONNECTIONLOST: Sent by the client to indicate that its connection to the server has been lost. In response to this message, the server shuts down all channels and connections.