Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2015 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2015.

Report 2015 Actions

    Problem Report Number 2015
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0593
    Raised 1999-12-03 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Transport Service XTI V2
    Certification Program The Open Brand certification program
    Test Suite VST version 5.2.4
    Test Identification XTI.os/cots/sndvudata 1
    Linked Problem Reports TSDT5.003, (in, old, system)
    Problem Summary PGT5R.001 The basic problem about test case T.sndvudata{1} is the same as in test case T.sndv{1} which is covered by TSDT5.003 i.e. the test is based on the assumption that all data sent off by a single call to...
    Problem Text
    The basic problem about test case T.sndvudata{1} is the same as in
    test case T.sndv{1} which is covered by TSDT5.003 i.e. the test is
    based on the assumption that all data sent off by a single call to
    t_sndv() resp. t_sndvudata() are transferred across the network as
    ONE message resp. datagram enabling the slave application to obtain
    all data by a single call to t_rcv() resp. t_rcvudata().

    Just as for test case T.sndv{1} we suggest to make the slave
    application call t_rcvudata() in a loop to make sure that no data
    have been lost instead of calling t_rcvudata() only once.

    We think that -concerning the transfer of data from non-contiguous
    buffers-- the same principles should apply for connection-oriented
    data as well as for datagrams. Therefore, we ask to treat this
    interpretation request in the same way as the interpretation request
    on T.sndv{1}.

    Test Output
    /tset/XTI.os/clts/sndvudata/T.sndvudata 1 Failed

    Test Description:

    If the implementation supports a connectionless transport service:
    When the current state of the endpoint is T_IDLE, and unitdata-
    >opt.len is set to zero, then a successful call to t_sndvudata(
    fd, unitdata iov, iovcount, ) sends the first iovcount number of
    buffers in the iov array of buffers to the destination specified
    in unitdata->addr, leaves the state of the transport unchanged
    from T_IDLE, and returns (int)0.

    Test Strategy:
    MASTER:
    VERIFY that the transport service is of type T_CLTS
    OBTAIN an endpoint in T_IDLE state using provsetup()
    INITIALISE send buffer with some data
    SEND a data unit to slave using t_sndvudata() from non-contiguous
    buffers
    SYNC with slave system using tet_sync()
    VERIFY that the endpoint state, outstanding events, and return
    value are as expected
    SLAVE:
    SYNC with master using tet_sync()
    WAIT for a T_DATA event using wait_event()
    RECEIVE a data unit from master using t_rcvudata()
    VERIFY that the received data in udata.buf is as expected

    Test Information

    Test Information From Slave:
    t_rcvudata() on UDP endpoint
    Expected data <abcdef>
    Actual data <abc>




    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The reason TSDT5.003 was granted was because the transport provider
    being tested (TCP) was stream-oriented, not because the data was
    being sent from non-contiguous buffers. In that request, the
    submitter stated that the use of a single receive call in the
    test "works fine for message-oriented transport systems, [but] does
    not for byte-stream-oriented transport systems".

    In this new request the transport provider being tested is UDP, which
    is message-oriented. The test is right to expect the entire datagram
    to be returned by a single t_rcvudata() call. This can be seen from
    the description of t_rcvudata() in the XNS specification, where the
    only reference to the T_MORE flag is in the following text:

    "If the buffer defined in the udata field of unitdata is not large
    enough to hold the current data unit, the buffer will be filled and
    T_MORE will be set in flags on return"

    There is no allowance here for T_MORE to be set when the buffer is
    large enough to hold the data unit.

    Contrast this with the description of t_rcv() where the specification
    states explicitly:

    "the T_MORE flag may be set on return from the t_rcv() call even when
    the number of bytes received is less than the size of the receive
    buffer specified."

    In order to return part of the data unit, t_rcvudata() would have to set
    the T_MORE flag. Since the specification only allows the T_MORE flag to
    be set when the receive buffer is too small, and the receive buffer in
    the test is not too small, an implementation of t_rcvudata() which does
    not return the entire data unit is not compliant with the specification.

    It is recommended that this request is refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority