1dat_ep_post_recv(3DADTi)rect Access Transport Library Functidoants_ep_post_recv(3DAT)
2
6 dat_ep_post_recv - receive data over the connection of the Endpoint
7
9 cc [ flag... ] file... -ldat [ library... ]
10 #include <dat/udat.h>
11 DAT_RETURN
13 dat_ep_post_recv (
14 IN DAT_EP_HANDLE ep_handle,
15 IN DAT_COUNT num_segments,
16 IN DAT_LMR_TRIPLET *local_iov,
17 IN DAT_DTO_COOKIE user_cookie,
18 IN DAT_COMPLETION_FLAGS completion_flags
19 )
20
23 ep_handle Handle for an instance of the Endpoint.
24 num_segments Number of lmr_triplets in local_iov. Can be 0 for
27 receiving a 0 size message.
28 local_iov I/O Vector that specifies the local buffer to be
31 filled. Can be NULL for receiving a 0 size message.
32 user_cookie: User-provided cookie that is returned to the Con‐
35 sumer at the completion of the Receive DTO. Can be
36 NULL.
37 completion_flags Flags for posted Receive. The default DAT_COMPLE‐
40 TION_DEFAULT_FLAG is 0x00. Other values are as fol‐
41 lows:
42 Notification of Completion DAT_COMPLE‐
44 TION_UNSIGNALLED_FLAG
45 0x04 Non-notifica‐
47 tion comple‐
48 tion. Local
49 Endpoint must
50 be configured
51 for
52 Unsignaled
53 CompletionNo‐
54 tification
55 Suppression.
56
61 The dat_ep_post_recv() function requests the receive of the data over
62 the connection of the ep_handle Endpoint of the incoming message into
63 the local_iov.
64 The num_segments parameter specifies the number of segments in the
67 local_iov. The local_iov segments are filled in the I/O Vector order
68 until the whole message is received. This ensures that all the "front"
69 segments of the local_iov I/O Vector are completely filled, only one
70 segment is partially filled, if needed, and all segments that follow it
71 are not filled at all.
72 The user_cookie allows Consumers to have unique identifiers for each
75 DTO. These identifiers are completely under user control and are opaque
76 to the Provider. There is no requirement on the Consumer that the value
77 user_cookie should be unique for each DTO. The user_cookie is returned
78 to the Consumer in the Completion event for the posted Receive.
79 The completion of the posted Receive is reported to the Consumer asyn‐
82 chronously through a DTO Completion event based on the configuration of
83 the connection for Solicited Wait and the specified completion_flags
84 value for the matching Send. The value of DAT_COMPLETION
85 _UNSIGNALLED_FLAG is only valid if the Endpoint Recv Completion Flags
86 DAT_COMPLETION_UNSIGNALLED_FLAG. Otherwise, DAT_INVALID_PARAMETER is
87 returned.
88 A Consumer must not modify the local_iov or its content until the DTO
91 is completed. When a Consumer does not adhere to this rule, the behav‐
92 ior of the Provider and the underlying Transport is not defined.
93 Providers that allow Consumers to get ownership of the local_iov but
94 not the memory it specified back after the dat_ep_post_recv() returns
95 should document this behavior and also specify its support in Provider
96 attributes. This behavior allows Consumer full control of the local_iov
97 content after dat_ep_post_recv() returns. Because this behavior is not
98 guaranteed by all Providers, portable Consumers should not rely on this
99 behavior. Consumers shouldnot rely on the Provider copying local_iov
100 information.
101 The DAT_SUCCESS return of the dat_ep_post_recv() is at least the equiv‐
104 alent of posting a Receive operation directly by native Transport.
105 Providers should avoid resource allocation as part of
106 dat_ep_post_recv() to ensure that this operation is nonblocking and
107 thread safe for an UpCall.
108 If the size of an incoming message is larger than the size of the
111 local_iov, the reported status of the posted Receive DTO in the corre‐
112 sponding Completion DTO event is DAT_DTO_LENGTH_ERROR. If the reported
113 status of the Completion DTO event corresponding to the posted Receive
114 DTO is not DAT_DTO_SUCCESS, the content of the local_iov is not
115 defined.
116 The operation is valid for all states of the Endpoint. The actual data
119 transfer does not take place until the Endpoint is in the
120 DAT_EP_STATE_CONNECTED state. The operation on the Endpoint in
121 DAT_EP_STATE_DISCONNECTED is allowed. If the operation returns success‐
122 fully, the posted Recv is immediately flushed to recv_evd_handle.
123
125 DAT_SUCCESS The operation was successful.
126 DAT_INSUFFICIENT_RESOURCES The operation failed due to resource lim‐
129 itations.
130 DAT_INVALID_PARAMETER Invalid parameter. For example, one of
133 the IOV segments pointed to a memory out‐
134 side its LMR.
135 DAT_INVALID_HANDLE The ep_handle parameter is invalid.
138 DAT_PROTECTION_VIOLATION Protection violation for local or remote
141 memory access. Protection Zone mismatch
142 between an LMR of one of the local_iov
143 segments and the local Endpoint.
144 DAT_PRIVILEGES_VIOLATION Privileges violation for local or remote
147 memory access. One of the LMRs used in
148 local_iov was either invalid or did not
149 have the local read privileges.
150
153 For best Recv operation performance, the Consumer should align each
154 buffer segment of local_iov to the Optimal Buffer Alignment attribute
155 of the Provider. For portable applications, the Consumer should align
156 each buffer segment of local_iov to the DAT_OPTIMAL_ALIGNMENT.
157
159 See attributes(5) for descriptions of the following attributes:
160 ┌─────────────────────────────┬─────────────────────────────┐
165 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
166 ├─────────────────────────────┼─────────────────────────────┤
167 │Interface Stability │Standard: uDAPL, 1.1, 1.2 │
168 ├─────────────────────────────┼─────────────────────────────┤
169 │MT-Level │Unsafe │
170 └─────────────────────────────┴─────────────────────────────┘
171
173 libdat(3LIB), attributes(5)
174SunOS 5.11 16 Jul 2004 dat_ep_post_recv(3DAT)