Report 1618 Actions
Problem Report Number |
1618 |
Submitter's Classification |
Specification problem |
State |
Resolved |
Resolution |
Permanent Interpretation (PIN) |
Problem Resolution ID |
PIN.X.0175 |
Raised |
1996-11-20 08:00 |
Updated |
2003-03-13 08:00 |
Published |
1996-11-25 08:00 |
Product Standard |
Sockets (UNIX 95) |
Certification Program |
The Open Brand certification program |
Test Suite |
VSU version 4.1.0 |
Test Identification |
CAPI.os/sockets/sendto 13,16 |
Specification |
Networking Services Issue 4 |
Location in Spec |
See Problem Text |
Problem Summary |
PIN4U.00041 This request contends the specification is incorrect. |
Problem Text |
We believe sendto #13, #16 and in sendmsg #16 are failing due to an unclear specification in X/Open CAE specification as it relates to specifying a destination address for a connectionless (UDP) socket that has already been connected. In addtion, the X/Open specification is inconsistent with POSIX Draft Standard P1003.1g/D6.4
X/Open CAE specification, Networking Services Issue 4 is unclear about the destination address parameter in the sendto() and sendmsg() definitions, for both connection-oriented and connection- less sockets.
For connection-oriented sockets, the description of sendto() in the specification states:
If the socket is connection-oriented, dest-addr is ignored.
The ERRORS section of the same specification states:
EISCONN A destination address was specified and the socket is connection-oriented and is already connected
The inconsistency here is that if the dest-addr is ignored for connection-oriented sockets, then the dest-addr cannot cause EISCONN errors for connection-oriented sockets.
The sendmsg specification contains similar text.
We have inspected two other sources, the 4.4BSD implementation and the POSIX P1003.1g/D6.4 draft in this respect.
The observed behavior in the 4.3BSD and 4.4BSD implementations is that the EISCONN error only occurs for connection-LESS sockets (and the destination address is ignored for connection-oriented sockets).
The POSIX P1003.1g/D6.4 draft differs from the X/Open specification. It makes no mention of dest-addr being ignored if the socket is connect ion- oriented, nor does refer to a socket type for the EISCONN error:
EISCONN A destination address was specified and the socket is already connected.
However, the POSIX draft states in section A.3.5.3.1:
When the connect() function is successfully called for a UDP socket, the remote address and port number shall be set for the endpoint. If the local port has not been bound, an unused local port number shall be bound to the endpoint. If the local address has not been bound, a local address shall be selected and bound. In the OPEN state, output operations shall not specify a destination address, and all datagrams shall be sent to the prespecified peer. Only datagrams from the prespecified peer shall be received.
Thus, the Draft Standard specifies that once a UDP socket has been connected, output operations (like sendto and sendmsg) shall not specify a destination address.
The tests in question, sendto #13 and #16, and sendmsg #16, seem to be based on the assumption that UDP sockets cannot get EISCONN errors. The tests operate on a UDP datagram socket and they first connect the socket (using the inet_client() function in the test suite) and also specify the destination address in the sendto and sendmsg calls.
Our interpretation of the sendto and sendmsg specifications, which is consistent with the POSIX draft specification, is that the tests in question should be subject to the EISCONN error because the dest- ination address is specified for a datagram socket that is already connected. (Please see the above reference on POSIX P1003.1g/D6.4 and 4.4BSD.)
We request that waivers be granted for the above mentioned test case failures on the basis of unclear and inconsistent specification.
The text of the specification for sendto() and sendmsg() can be made consistent within the X/Open specification itself by changing it from:
EISCONN A destination address was specified and the socket is connection-oriented and is already connected. to:
EISCONN A destination address was specified and the socket is connection-less and is already connected. However, other changes that more closely align the specification with the POSIX draft might be more appropriate.
|
Test Output |
TEST CASE: sendto
TEST PURPOSE #13 If the implementation supports a communications domain and a socket type: EMSGSIZE in errno and return -1 on a call to ssize_t sendto(int socket, const void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t dest_len) when the message is too large to be sent at once as the socket requires. PREP: Allocate a big buffer and fill with '#'. TEST: AF_INET SOCK_DGRAM PREP: Create test sockaddr_in: address = 129.146.85.212, port = 2153 PREP: Server: create socket PREP: Server: bind address 129.146.85.212, port 2153 to socket PREP: Server: notify client server is ready PREP: Server: read and echo data INFO: Server received signal 15 INFO: Server terminated PREP: Wait for server to be ready PREP: Create a socket PREP: Connect socket to address 129.146.85.212, port 2153 TEST: send huge message TEST: Return value TEST: errno value ERROR: sendto call failed incorrectly, errno was 133(EISCONN - Socket i s connected) should have been EMSGSIZE CLEANUP: Send SIGTERM to server 13 FAIL
TEST PURPOSE #16 If the implementation supports a communications domain and a connectionless socket type: EOPNOTSUPP in errno and return -1 on a call to ssize_t sendto(int socket, const void *message, size_t length, int flags, const struct sockaddr *dest_addr, size_t dest_len) when the specified flags are not supported for this type of socket. TEST: AF_INET SOCK_DGRAM PREP: Create test sockaddr_in: address = 129.146.85.212, port = 4953 PREP: Server: create socket PREP: Server: bind address 129.146.85.212, port 4953 to socket PREP: Server: notify client server is ready PREP: Server: read and echo data INFO: Server received signal 15 INFO: Server terminated PREP: Wait for server to be ready PREP: Create a socket PREP: Connect socket to address 129.146.85.212, port 4953 TEST: send message with MSG_OOB in flags TEST: Return value TEST: errno value ERROR: sendto call failed incorrectly, errno was 133(EISCONN - Socket i s connected) should have been EOPNOTSUPP CLEANUP: Send SIGTERM to server 16 FAIL
TEST CASE: sendmsg
TEST PURPOSE #16 If the implementation supports a communications domain and a connectionless socket type: EOPNOTSUPP in errno and return -1 on a call to ssize_t sendmsg(int socket, const struct msghdr *message, int flags) when the specified flags are not supported for this type of socket. TEST: AF_INET SOCK_DGRAM PREP: Create test sockaddr_in: address = 129.146.85.212, port = 4769 PREP: Server: create socket PREP: Server: bind address 129.146.85.212, port 4769 to socket PREP: Server: notify client server is ready PREP: Server: read and echo data INFO: Server received signal 15 INFO: Server terminated PREP: Wait for server to be ready PREP: Create a socket PREP: Connect socket to address 129.146.85.212, port 4769 TEST: send message with MSG_OOB in flags TEST: Return value TEST: errno value ERROR: sendmsg call failed incorrectly, errno was 133(EISCONN - Socket is connected) should have been EOPNOTSUPP CLEANUP: Send SIGTERM to server 16 FAIL
|
Review Information
Review Type |
TSMA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Recommendation |
No Resolution Given |
Review Response |
We recommend this request be refused.
The submitter's argument may have merit, but we believe the specification is clear and the test is consistent with the spec wording.
IRs are designed to interpret, but not to modify the specification. If the submitter wishes to pursue this we suggest he file a base resolution request.
|
Review Type |
Expert Group Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
No Resolution Given |
Review Conclusion |
The specification is clearly self-contradictory. A Permanent Interpretation should therefore be granted, and a revision of the specification to remove the contradiction should be considered by the Working Group.
|
Review Type |
SA Review |
Start Date |
null |
Completed |
null |
Status |
Complete |
Review Resolution |
Permanent Interpretation (PIN) |
Review Conclusion |
A Permanent Interpretation is granted.
|
Problem Reporting System Options:
|