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 |
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.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
9371.1 | NETRIX::"[email protected]" | Brian Haley | Thu Apr 03 1997 11:41 | 17 | |
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.2 | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Mon Apr 07 1997 19:19 | 15 | |
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. |