Numeric Values of Message Type codes The Table 4 defines the numeric values of the Message Type codes. Table Message Type Value Definitions Designation Channel Numeric Value (decimal) Initialize Synchronous 0 InitializeResponse Synchronous 1 FatalError Synchronous 2 Synchronous 3 AsyncLock Asynchronous 4 AsyncLockResponse Asynchronous 5 Data Synchronous 6 DataEnd Synchronous 7 DeviceClearComplete Synchronous 8 DeviceClearAcknowledge Asynchronous 9 AsyncRemoteLocalControl Asynchronous 10 AsyncRemoteLocalResponse Asynchronous 11 Trigger Synchronous 12 Interrupted Synchronous 13 AsyncInterrupted Asynchronous 14 AsyncMaximumMessageSize Asynchronous 15 AsyncMaximumMessageSizeResponse Asynchronous 16 AsyncInitialize Asynchronous 17 AsyncInitializeResponse Asynchronous 18 AsyncDeviceClear Asynchronous 19 AsyncServiceRequest Asynchronous 20 AsyncStatusQuery Asynchronous 21 AsyncStatusResponse Asynchronous 22 AsyncDeviceClearAcknowledge Asynchronous 23 AsyncLockInfo Asynchronous 24 AsyncLockInfoResponse Asynchronous 25 reserved for future use 26-127 VendorSpecific Either 128-255 inclusive
AsyncRemoteLocalControl transactions are completed. However, the client shall not wait for locks on other clients to be released. If another client is holding a lock, the server shall only act on the remote/local request after the lock is released. The behavior is device dependent. AsyncServiceRequest messages are sent normally. All synchronous messages are left in the input buffer. Normal TCP behavior to prevent buffer overflows takes place. Data, DataEND, Trigger, Error, FatalError, and VendorSpecific messages are left in the input buffer. Data traffic from the server to the client (Data and DataEND messages) are sent normally. However, since incoming synchronous messages are blocked, only responses to operations that were begun before the lock was granted will be generated.
When receiving Data messages if the MessageID is not 0xffff ffff, then verify that the MessageID indicated in the Data message is the MessageID that the client sent to the server with the most recent Data, DataEND or Trigger message. If the MessageIDs do not match, the client shall clear any Data responses already buffered and discard the offending Data message. When the client sends Data, DataEND or Trigger if there are any whole or partial server messages that have been validated per rules and and buffered they shall be cleared. When the client receives Interrupted or AsyncInterrupted it shall clear any whole or partial server messages that have been validated per rules and . If the client initially detects AsyncInterrupted it shall also discard any further Data or DataEND messages from the server until Interrupted is encountered. If the client detects Interrupted before it detects AsyncInterrupted, the client shall not send any further messages until AsyncInterrupted is received. Clients shall maintain a MessageID count that is initially set to 0xffff ff00. When clients send Data, DataEND or Trigger messages, they shall set the message parameter field of the message header to the current MessageID and increment the MessageID by two in an unsigned 32-bit sense (permitting wrap-around). The MesssageID is reset to 0xffff ff00 after device clear, and when the connection is initialized. After interrupted error processing is complete, the client resumes normal operation.
Accept and ignore subsequent synchronous messages until it finds the synchronous DeviceClearComplete message. Send DeviceClearAcknowledge message back to the client (after the above steps are complete and it has received the device clear complete message). Resume normal operation. If at any time during device management either the client or server encounter a poorly formed message they shall send a FatalError message and do the FatalError processing. If at any time during the device clear management the client or server determines that the other device is not responding in a timely fashion, it shall send a FatalError message and do the FatalError processing. The determination of an appropriate time may vary with the application, 40 to 120 seconds are reasonable values. Feature Negotiation During device clear, the features listed in Table 24 are negotiated between the client and server. The features are specified through a feature bitmap that is sent in the control code of three different messages. The feature negotiation occurs in three steps: The server proposes values that it prefers with the AsyncDeviceClearAcknowledge message. The client indicates values that it requests in the DeviceClearComplete messge. The server indicates the values that both client and server will use in the DeviceClearAcknowledge message. The server shall identify the default values it prefers for the features in the AsyncDeviceClearAcknowledge message. Servers shall support any such capabilities that it requests. The server shall accept the value proposed by the client in the DeviceClearComple message if it is capable of supporting them. The client shall use the values specified by the server in the DeviceClearAcknowledge message. Note that the InitializeResponse has the server preferred feature specified in it. Features negotiated during device clear Control Code Bit Position Name Meaning 0 Overlapped False- Synchronized mode True - Overlapped mode