| OpenSS7 SS7 for the Common Man | © Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved. Last modified: Sat, 01 Nov 2008 10:41:52 GMT | ||||||||||||||||
| |||||||||||||||||
| Description: Manual PageKeywords: ss7 ss7/ip ss7 over ip ss7 mtp ss7 sccp ss7 tcap sigtran mtp sccp tcap openss7 acb56 linux telephony pstn linux telephony linux nebs linux compactpciM_PCPROTOSection: Linux Fast-STREAMS DDI/DKI (9)Updated: 2008-10-31 Index Return to Main Contents NAMEM_PCPROTO - STREAMS priority protocol messageFORMATThe M_PCPROTO message block is a datab(9) structure and associated data buffer that contains unstructured data. (Any structure imposed on the M_PCPROTO data buffer is defined outside of STREAMS.) An M_PCPROTO message is a high priority message that consists of one or more M_PCPROTO message blocks followed by zero or more M_DATA(9) message blocks. INTERFACEDESCRIPTIONThe M_PCPROTO message is intended to contain high priority control information and associated data. The message format is one or more M_PCPROTO message blocks followed by zero or more M_DATA(9) message blocks. (Note that a user level process can only generate M_PCROTO messages containing a single M_PCPROTO message block followed by one or more M_DATA(9) message blocks when using the putmsg(2) or putpmsg(2s) system calls.) The semantics of the M_PCPROTO and M_DATA(9) message blocks are determined by the STREAMS module that receives the message, and is normally defined as part of the service interface description between modules. For example, the Transport Provider Interface, tpi(7), describes the format of M_PCPROTO and M_DATA(9) message blocks contained in M_PCPROTO messages that are passed to a driver or module implementing the tpi(7) service interface. The service interface exists between the user level process and the receiving driver or module, or, between drivers and modules. The M_PCPROTO message block will normally contain high priority service interface control information and the M_DATA(9) message blocks will normally contain service interface user data. M_PCPROTO messages are generally sent in both the downstream and upstream directions on a Stream. M_PCPROTO messages sent upstream and arriving at the Stream head are available to be read by user level processes using the read(2s), getmsg(2), or getpmsg(2s) system calls. M_PCPROTO messages can be sent downstream from the Stream head by a user level process using the putmsg(2), or putpmsg(2s) system calls. (The write(2s) cannot be used to generate M_PCPROTO messages.) When describing STREAMS-specific system calls, the contents of the M_PCPROTO message block is referred to as the control part, and any M_DATA(9) message blocks contained in the message are referred to collectively as the data part. For the getmsg(2), getpmsg(2s), putmsg(2), and putpmsg(2s) system calls, the control and data parts are passed separately. For the read(2s) system call, the control and data parts are optionally passed together, or the the control part is discarded. Although its use is not recommended, the format of M_PCPROTO and M_PROTO(9) (generically PROTO) messages sent upstream to the Stream head allows multiple PROTO blocks at the beginning of the message. getmsg(2), getpmsg(2s), and read(2s), will compact multiple PROTO blocks into a single control part, multiple M_DATA(9) blocks, as single data part, when passing them to the user process. The putmsg(2) and putpmsg(2s) system calls will never generate a M_PCPROTO message with more than one M_PCPROTO message block, but may generate M_PCPROTO messages that contain more than one M_DATA(9) message block. M_PCPROTO messages, by nature of the initial block message type, are high-priority messages, and are, therefore, not subject to flow control restrictions within a Stream. In contrast, the M_PROTO(9) message is a normal priority message serving the same purpose, that is subject to flow control restrictions. When an M_PCPROTO message is placed on a queue, that queue's qi_srvp(9) procedure is always enabled. The Stream head will allow only one M_PCPROTO message to be placed in its read queue at a time. If an M_PCPROTO message is already in the queue when another arrives, the second message is silently discarded and its message blocks freed. M_PCPROTO messages can be generated directly by user level processes using the putmsg(2) and putpmsg(2s) system calls. M_PCPROTO messages can be consumed by user level processes using the read(2s), getmsg(2), and getpmsg(2s) system calls. M_PCPROTO message can be generated by drivers and modules. USAGEM_PROTO(9) and M_PCPROTO messages are the work horses of a service interface under STREAMS. They are generated by both user level processes as well as drivers and modules. These messages normally represent service primitives within a service interface definition at a message passing boundary within a Stream. The M_PCPROTO data buffer usually has a defined structure with an initial member that identifies the service primitive, and additional members that provide the parameters associated with the service primitive. The M_DATA(9) data buffers that follow usually contain unstructured user data. EXAMPLESFor an example of the formulation of a M_PCPROTO message, see the examples for the M_PROTO(7) message. Aside from being a high-priority message, M_PCPROTO messages are used in an identical manner to M_PROTO(7) messages. SEE ALSOread(2s), write(2s), getmsg(2), putmsg(2), getpmsg(2s), putpmsg(2s), datab(9), msgb(9). COMPATIBILITYThe M_PCPROTO STREAMS message is compatible with SVR 4.2 MP STREAMS, and implementations based on SVR 4, with the following portability considerations:
See STREAMS(9) for additional compatibility information. CONFORMANCEHISTORYThe M_PCPROTO message first appeared in SVR 3[4]. REFERENCES
TRADEMARKS
Other trademarks are the property of their respective owners. IDENTIFICATION
Copyright©1997-2008OpenSS7 Corp.
All Rights Reserved.
Index
This document was created by man2html, using the manual pages. Time: 12:03:57 GMT, May 24, 2013 | ||||||||||||||||
| OpenSS7 SS7 for the Common Man |
| ||||||||||||||||
| Last modified: Sat, 01 Nov 2008 10:41:52 GMT © Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved. |