imination is wanted, the integrator protocol must provide it by including a mes- sage type identifier (MTid) in a fixed position in every message, see Fig. 5.11. Note, however, that the discriminator becomes very closely coupled to the service elements in this case. A variant of this theme is that no explicit MTid exists. The discriminator analyses the complete messages, in order to decide which protocol element must deal with it. If a CSP supports message type identification, it supports a form of selective receive (see Sect. 3.2.5). Proprietary CSPs may support message type discrimina- tion. A very efficient message type discrimination method (for real time applica- tions) is used in my company, supported by a proprietary platform and an in-house 5.3 Discrimination language (Plex). This platform provides routing based on message type identifiers, in addition to more conventional routing based on logical node addresses (SAPIs), see Fig. 5.16. Logical node Parameters defined by M1 State Parameters defined by M2 X (SAPI) recCnlRepCnf(messType,SDU) sendCnlOrd(messType, SET OF destSAPI OPTIONAL, SDU) Send-table for Node platform CSP logical node X: destSAPI Fig. 5.16 Message type discrimination supported by a node platform The logical nodes are, in this case, built like state machines. Instead of service elements, there is a message type handler (MTH) for each received message type (M1 and M2 in Fig. 5.16). Each MTH handles a transaction, defined by the message type. Before the transaction ends, one or several messages (M3 and M4 in Fig. 5.16) may be sent to other logical nodes. Since there exist dependencies between consec- utive transactions in a state machine, the logical node must include a data object (State data) that records state changes of the logical node (if relevant). The node platform offers very special send and receive operations to logical node designers. There are two possible address parameters: a message type identi- fier and an (optional) SAPI. When the logical network becomes configured on the n