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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1975 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 1975.

Report 1975 Actions

    Problem Report Number 1975
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0238
    Raised 1996-09-20 08:00
    Updated 2003-03-13 08:00
    Published 1996-10-28 08:00
    Product Standard Transport Service XTI
    Certification Program The Open Brand certification program
    Test Suite VST version 4.1.3
    Test Identification XTI.os/cots/rcvdis 1
    Specification Networking Services Issue 4
    Location in Spec See Problem Text
    Problem Summary PINT4.004 Due to some TCP-specific behaviour a connection may first be accepted by the TCP transport provider before the partner application rejects it. Thus, a T_CONNECT event is placed in the event queue befo...
    Problem Text
    Due to some TCP-specific behaviour a connection may first be accepted by the
    TCP transport provider before the partner application rejects it.
    Thus, a T_CONNECT event is placed in the event queue before the
    T_DISCONNECT event arrives. Acc. to "Network Services, Issue 4", chapter 3.7,
    paragraph "Events and t_look()", "an event is outstanding (..) until it is
    consumed". As may be seen from the table below, t_rcvdis() is no consuming
    function for a pending T_CONNECT event. This is why the T_CONNECT remains
    unconsumed in this test case. Our implementation reports TNODIS
    as the outstanding event visible via t_look() is not T_DISCONNECT.
    The verification suite, however, expects the T_CONNECT event to be
    discarded by the subsequent T_DISCONNECT i.e. two events are consumed
    by a single call to a consuming function (t_rcvdis()).
    Actually, we can't see that the specification requires an XTI implementation
    to do so.

    Test Output
    /tset/XTI.os/cots/rcvdis/T.rcvdis 1 Unresolved
    Test Information:
    t_rcvdis() on TCP endpoint:
    RETURN VALUES: expected: 0, observed: -1
    TERRNO VALUES: expected: 0 (NO ERROR), observed: 14 (TNODIS)

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    There appears to be a problem with the XTI specification in the case of
    a t_rcvdis() call in the T_OUTCON state when both a T_CONNECT and a
    T_DISCONNECT event have occurred. It requires the t_rcvdis() call to
    consume the T_DISCONNECT and change the state to T_IDLE, and it requires
    that outstanding events remain outstanding until they are consumed.
    The only functions that are listed as consuming T_CONNECT events are
    t_connect() and t_rcvconnect(). If these requirements are followed,
    this leads to the situation of the T_CONNECT event being "left-over"
    after the t_rcvdis() call. Clearly this is not a desirable state of
    affairs, since the connection to which the event relates has already
    been broken at the remote end, and the presence of a T_CONNECT event is
    inconsistent with the T_IDLE state.

    Implementations which pass this test are discarding the T_CONNECT event,
    contrary to the apparent requirements of the specification. However,
    this behaviour seems reasonable: by calling t_rcvdis() instead of
    t_rcvconnect() the application can be considered to have indicated that
    it is not interested in the T_CONNECT event.

    The submitter's implementation attempts to solve the problem a different
    way, by returning a TNODIS error. This does not seem appropriate,
    since the condition for which TNODIS should be returned is "no disconnect
    indication currently exists on the specified transport endpoint."
    In the situation in question a disconnect indication does exist, even
    if an application cannot tell it exists by calling t_look(). (The
    application could have `outside' knowledge of the disconnect - the VST
    test suite is one such application.)

    This issue can only be resolved by a change to the specification, and
    so it should be referred to the XNET working group.

    The most appropriate change, in the consultant's opinion, would be to
    require that t_rcvdis() consumes the T_CONNECT event as well as the
    T_DISCONNECT, reflecting the current behaviour of branded systems.
    Alternatively the specification could allow either behaviour (i.e. the
    implementation can either consume the T_CONNECT or return a TNODIS error),
    although this would necessitate a change to the definition of TNODIS.
    Another alternative would be to state explicitly that the behaviour
    in this situation is unspecified.

    It should be noted that although this issue only affects the VST test
    suite when testing TCP transport providers, the situation of a t_rcvdis()
    call in the T_OUTCON state when both a T_CONNECT and a T_DISCONNECT event
    are outstanding can also occur for ISO and other transport providers that
    do not auto-accept connection requests. The current behaviour of these
    implementations should also be taken into account.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    There are two possible scenarios:
    1) The T_DISCONNECT event isn't visible at the interface until the
    T_CONNECT event has been consumed.

    2) The T_CONNECT event is discarded when the T_DISCONNECT event is
    queued, making the T_DISCONNECT event visible on the endpoint.

    Both are arguably valid interpretations of the XTI specification and
    should be allowed by the test suite.

    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:

     

    Back   

Contact the Certification Authority