[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9371.0. "TRESADDR returned from t_accept when using tcp+" by CSC64::BLAYLOCK (If at first you doubt,doubt again.) Wed Apr 02 1997 20:39

Digital UNIX V4.0A (rev 464)
$RCSfile: xtiso.c,v $ $Revision: 4.4.37.8 $ (DEC) $Date: 1995/11/15

Using the examples in /usr/examples/network_programming
XOPEN_SOURCE is set in CFLAGS in the make file
Change the streams device from from /dev/streams/xtiso/tcp to
/dev/streams/xtiso/tcp+

In the above conditions (which is what the network programming
guide recommends), on the t_accept call in the xtiserver example,
the t_errno value is set to 27 - TRESADDR

This error value is not documented (even using a COMET search),
so what is the cause of this error condition?

This is the call, and xtifd and newxtifd are not the same.

                /* accept connection */
                if (t_accept(xtifd, newxtifd, call) < 0) {
                        xerror("xti_accept", xtifd);
                        exit(7);
                }

Even if they are the same fd, it fails.  If the same service address is
applied to the t_bind call (instead of NULL) you still get this error.

What is the proper mechanism for setting up this call and is there
any futher documentation on the TRESADDR error condition?
T.RTitleUserPersonal
Name
DateLines
9371.1NETRIX::&quot;[email protected]&quot;Brian HaleyThu Apr 03 1997 11:4117
Hi,

> TRESADDR -  This error value is not documented

If you mean it's not on the man page, then file a qar, you obviously
found it in /usr/include/xti.h.

As far as using the tcp+ transport, it's not as trivial as just adding
the -DXOPEN_SOURCE and recompiling, the Network Programmers Guide states
this clearly: "If you need to use the new features supported by SPEC1170
XTI, you will have to make changes in your source code."

The simple example is just that - simple, and I don't believe it was
intended to be used in a XPG4 environment.

-Brian
[Posted by WWW Notes gateway]
9371.2CSC64::BLAYLOCKIf at first you doubt,doubt again.Mon Apr 07 1997 19:1915

Actually, the paragraph right after the one you quoted 
does state that the source code changes are as simple
as change the t_open call and compile all sources with
_XOPEN_SOURCE.

However, the real answer appears to be to not call t_bind
on the new fd (resfd) but leave the connection in an unbound
state.  Digital UNIX does not accept resfd being in a 
T_IDLE state if fd!=resfd.  This is despite the XTI specification
where the only requirement on the t_bind is that qlen=0
(P1003.1g/D6.1, May 1995 section 4.4.2.2)

This has been elevated.