This manual page is derived from the DAT/uDAPL 1.2 specification.
Portions Copyright (c) 2007, Sun Microsystems, Inc. All Rights Reserved.
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
cc [ flag.\|.\|. ] file.\|.\|. -ldat [ library.\|.\|. ] #include <dat/udat.h> DAT_RETURN dat_ep_post_recv ( IN DAT_EP_HANDLE ep_handle, IN DAT_COUNT num_segments, IN DAT_LMR_TRIPLET *local_iov, IN DAT_DTO_COOKIE user_cookie, IN DAT_COMPLETION_FLAGS completion_flags )
ep_handle
Handle for an instance of the Endpoint.
num_segments
Number of lmr_triplets in local_iov. Can be 0 for receiving a 0 size message.
local_iov
I/O Vector that specifies the local buffer to be filled. Can be NULL for receiving a 0 size message.
user_cookie:
User-provided cookie that is returned to the Consumer at the completion of the Receive DTO. Can be NULL.
completion_flags
Flags for posted Receive. The default DAT_COMPLETION_DEFAULT_FLAG is 0x00. Other values are as follows:
Notification of Completion
DAT_COMPLETION_UNSIGNALLED_FLAG
0x04
Non-notification completion. Local Endpoint must be configured for Unsignaled CompletionNotification Suppression.
The dat_ep_post_recv() function requests the receive of the data over the connection of the ep_handle Endpoint of the incoming message into the local_iov.
The num_segments parameter specifies the number of segments in the local_iov. The local_iov segments are filled in the I/O Vector order until the whole message is received. This ensures that all the "front" segments of the local_iov I/O Vector are completely filled, only one segment is partially filled, if needed, and all segments that follow it are not filled at all.
The user_cookie allows Consumers to have unique identifiers for each DTO. These identifiers are completely under user control and are opaque to the Provider. There is no requirement on the Consumer that the value user_cookie should be unique for each DTO. The user_cookie is returned to the Consumer in the Completion event for the posted Receive.
The completion of the posted Receive is reported to the Consumer asynchronously through a DTO Completion event based on the configuration of the connection for Solicited Wait and the specified completion_flags value for the matching Send. The value of DAT_COMPLETION _UNSIGNALLED_FLAG is only valid if the Endpoint Recv Completion Flags DAT_COMPLETION_UNSIGNALLED_FLAG. Otherwise, DAT_INVALID_PARAMETER is returned.
A Consumer must not modify the local_iov or its content until the DTO is completed. When a Consumer does not adhere to this rule, the behavior of the Provider and the underlying Transport is not defined. Providers that allow Consumers to get ownership of the local_iov but not the memory it specified back after the dat_ep_post_recv() returns should document this behavior and also specify its support in Provider attributes. This behavior allows Consumer full control of the local_iov content after dat_ep_post_recv() returns. Because this behavior is not guaranteed by all Providers, portable Consumers should not rely on this behavior. Consumers shouldnot rely on the Provider copying local_iov information.
The DAT_SUCCESS return of the dat_ep_post_recv() is at least the equivalent of posting a Receive operation directly by native Transport. Providers should avoid resource allocation as part of dat_ep_post_recv() to ensure that this operation is nonblocking and thread safe for an UpCall.
If the size of an incoming message is larger than the size of the local_iov, the reported status of the posted Receive DTO in the corresponding Completion DTO event is DAT_DTO_LENGTH_ERROR. If the reported status of the Completion DTO event corresponding to the posted Receive DTO is not DAT_DTO_SUCCESS, the content of the local_iov is not defined.
The operation is valid for all states of the Endpoint. The actual data transfer does not take place until the Endpoint is in the DAT_EP_STATE_CONNECTED state. The operation on the Endpoint in DAT_EP_STATE_DISCONNECTED is allowed. If the operation returns successfully, the posted Recv is immediately flushed to recv_evd_handle.
DAT_SUCCESS
The operation was successful.
DAT_INSUFFICIENT_RESOURCES
The operation failed due to resource limitations.
DAT_INVALID_PARAMETER
Invalid parameter. For example, one of the IOV segments pointed to a memory outside its LMR.
DAT_INVALID_HANDLE
The ep_handle parameter is invalid.
DAT_PROTECTION_VIOLATION
Protection violation for local or remote memory access. Protection Zone mismatch between an LMR of one of the local_iov segments and the local Endpoint.
DAT_PRIVILEGES_VIOLATION
Privileges violation for local or remote memory access. One of the LMRs used in local_iov was either invalid or did not have the local read privileges.
For best Recv operation performance, the Consumer should align each buffer segment of local_iov to the Optimal Buffer Alignment attribute of the Provider. For portable applications, the Consumer should align each buffer segment of local_iov to the DAT_OPTIMAL_ALIGNMENT.
See attributes(5) for descriptions of the following attributes:
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Interface Stability | Standard: uDAPL, 1.1, 1.2 |
| MT-Level | Unsafe |
libdat(3LIB), attributes(5)