cified receive, CON: Specific receive, CNL: recConRequest(specification) recCnlRequest(specification) recConConfirm(SDU,...) TreeCnIConfirm(SDU,...) reeConRefuse() recCnlRefuse() Fig. 3.27 Message discrimination at reception General receive implies that the user accepts any received data (i.e. SDU) from any other sender. This type of receive does not normally require large receive buffers in the CSP. Negative responses tell the user that there are no data in any receive buffer. 3.2 The Communication Service Provider Addressed receive implies that the user specifies (in the request) from which sender he wants data (by CEI or SAPI parameters). Larger receive buffers may be required. Negative responses tells the user that there are no data from the par- ticular CEI or SAPI. Specified receive implies that the user provides a specification of the data in the SDU that directs the CSP to any of a number of possibly received SDUs he is prepared to receive (which might also comprise specific CEIs or SAPIs). Nega- tive responses tell the user that there are no messages of the specified type. Specified receive is efficient in real-time, proprietary system implementations, since the user does not have to check which message type is received. For example, my company uses an internally developed software language (called Plex) that is based on this principle. There is, however, a price to be paid: the specification parameter in the request refers to data that belong to the message specification of the protocol that are used between users. The function of the CSP therefore depends on that protocol. For this reason, specified receive should never be used in "open system" environments, since otherwise open connectivity services, like IP, TCP, MTP, SCCP and X.25 cannot be used. It is therefore not a recommended method in SM&AML. When defining send and receive operations for SAPs, one has to consider the distributed nature of CSPs, i.e. of the communication between terminal systems, and between terminal system and the operator netw