Documentation Archive Developer
Search

ADC Home > Reference Library > Technical Q&As > Networking > Carbon >

Not Recommended Documentclose button

Important: The information in this document is Not Recommended and should not be used for new development.

Current information on this Reference Library topic can be found here:

Closing the Connection: OpenTransport


Q: I am writing an OpenTransport client program, and I'm confused as to how to perform an orderly release when I receive the T_ORDREL message.

When I get the T_ORDREL message I'm supposed to call RcvOrderlyDisconnect. The docs for RcvOrderlyDisconnect say that I can then continue to send data, but I cannot read data without getting an outState error.

Is this correct?

A: Yes, it is. Your confusion is due more to the dynamics and subtleties of XTI programming than to OpenTransport.

In an orderly disconnect situation, assume that two nodes have an established TCP connection. Endpoint A has finished sending data and indicates closure by invoking a SndOrderlyDisconnect call (this translates into sending a end-of-file signal (FIN) over the wire).

Endpoint B receives a T_ORDREL message. If, however, B has not finished receiving the data, then B must continue calling into Rcv until it gets back kOTNoDataErr. At this point, B initiates a RcvOrderlyDisconnect (which acknowledges A's FIN).

This is known as a "half-close." B can still call Snd to send data to A (which will still receive T_DATA events); but if A attempts to send, it will receive an out-of-state Error.

Once B has finished receiving the data, it must initiate a SndOrderlyDisconnect -- resulting in sending A a FIN. A should also continue accepting data until receiving kOTNoDataError. A should then call RcvOrderlyDisconnect, thereby completing the link teardown. Both sides can then unbind.

If, however, either endpoint's network code is written such that T_ORDREL and T_DATA events are handled at different priorities, (for instance, the T_ORDREL is handled at the notifier, but the T_DATA is deferred to systemTask time) then a race condition can occur. Your program must establish that all data has been read before calling RcvOrderlyDisconnect.

There is also a subtlety of XTI programming that you should be aware of. It is possible that SndOrderlyDisconnect or RcvOrderlyDisconnect will return with a TLOOK error. This means that there is another event pending; your program must call OTLook to gather that event.

According to the XTI spec ("Section 4.6 Events and TLOOK Error indication"), the SndOrderlyDisconnect and RcvOrderlyDisconnect calls can fail because of a pending T_DISCONNECT event. This is XTI trying to tell you that the a connection on that endpoint broke. This can happen in this asynchronous wacky world of networks and your program will have to call a RcvDisconnect to acknowledge that your endpoint dropped.

You might want to check out the OTI spec, which, although it is not always written in the most lucid fashion, does contain valuable information for those involved in OpenTransport programming.

Further Information:

Title: X/OPEN TRANSPORT INTERFACE (XTI) VER 2 [ 1.0 ed]
Author: X/OPEN
ISBN #: 0133534596

[Mar 04 1996]