3.1 Client Details
Note Regarding concurrent programming, also known as multi-threaded programming: The processing rules for the client role MUST be processed atomically up to the point where the client is waiting for a message, packet or higher layer event. When the client is transmitting a message, it MUST transmit it in an asynchronous manner.
For example, as the client is processing a message, a higher-layer event is not possible until the client starts waiting for another message, packet, or event. If the client sends a message, it needs to make sure that TCP flow control does not cause it to "block" while sending the message. Similarly, as the client is processing a higher layer event, the receipt of a packet or the expiry of a timer cannot interrupt processing of that higher-layer event until the client starts waiting for a message, packet, or event.
Implementers can create such serialization of the processing rules using synchronization primitives available in their target programming language. As an example, such primitives can be called "critical sections" or "mutexes".
Unless otherwise specified, the protocol reports the occurrence of an error to the higher layer, stops all timers, and stops processing further messages. Possible errors include the following:
Failure to connect to the server.
The connection to the server is unexpectedly closed.
Receipt of a message in which the HRESULT field specifies an error value.
A malformed message is received (for example, a LinkMacToViewerReportConnectedEx message does not adhere to the syntax for messages of that type).