1t_accept(3NSL) Networking Services Library Functions t_accept(3NSL)
2
6 t_accept - accept a connection request
7
9 #include <xti.h>
10 int t_accept(int fd, int resfd, const struct t_call *call);
15
18 This routine is part of the XTI interfaces that evolved from the TLI
19 interfaces. XTI represents the future evolution of these interfaces.
20 However, TLI interfaces are supported for compatibility. When using a
21 TLI routine that has the same name as an XTI routine, a different
22 header file, tiuser.h, must be used. Refer to the TLI COMPATIBILITY
23 section for a description of differences between the two interfaces.
24 This function is issued by a transport user to accept a connection
27 request. The parameter fd identifies the local transport endpoint
28 where the connection indication arrived; resfd specifies the local
29 transport endpoint where the connection is to be established, and call
30 contains information required by the transport provider to complete the
31 connection. The parameter call points to a t_call structure which con‐
32 tains the following members:
33 struct netbuf addr;
35 struct netbuf opt;
36 struct netbuf udata;
37 int sequence;
38 In call, addr is the protocol address of the calling transport user,
42 opt indicates any options associated with the connection, udata points
43 to any user data to be returned to the caller, and sequence is the
44 value returned by t_listen(3NSL) that uniquely associates the response
45 with a previously received connection indication. The address of the
46 caller, addr may be null (length zero). Where addr is not null then it
47 may optionally be checked by XTI.
48 A transport user may accept a connection on either the same, or on a
51 different, local transport endpoint than the one on which the connec‐
52 tion indication arrived. Before the connection can be accepted on the
53 same endpoint (resfd==fd), the user must have responded to any previous
54 connection indications received on that transport endpoint by means of
55 t_accept() or t_snddis(3NSL). Otherwise, t_accept() will fail and set
56 t_errno to TINDOUT.
57 If a different transport endpoint is specified (resfd!=fd), then the
60 user may or may not choose to bind the endpoint before the t_accept()
61 is issued. If the endpoint is not bound prior to the t_accept(), the
62 endpoint must be in the T_UNBND state before the t_accept() is
63 issued, and the transport provider will automatically bind it to an
64 address that is appropriate for the protocol concerned. If the trans‐
65 port user chooses to bind the endpoint it must be bound to a protocol
66 address with a qlen of zero and must be in the T_IDLE state before the
67 t_accept() is issued.
68 Responding endpoints should be supplied to t_accept() in the state
71 T_UNBND.
72 The call to t_accept() may fail with t_errno set to TLOOK if there are
75 indications (for example connect or disconnect) waiting to be received
76 on endpoint fd. Applications should be prepared for such a failure.
77 The udata argument enables the called transport user to send user data
80 to the caller and the amount of user data must not exceed the limits
81 supported by the transport provider as returned in the connect field of
82 the info argument of t_open(3NSL) or t_getinfo(3NSL). If the len field
83 of udata is zero, no data will be sent to the caller. All the maxlen
84 fields are meaningless.
85 When the user does not indicate any option (call→opt.len = 0) the con‐
88 nection shall be accepted with the option values currently set for the
89 responding endpoint resfd.
90
92 Upon successful completion, a value of 0 is returned. Otherwise, a
93 value of -1 is returned and t_errno is set to indicate an error.
94
96 fd: T_INCON
97 resfd (fd!=resfd): T_IDLE, T_UNBND
100
102 On failure, t_errno is set to one of the following:
103 TACCES The user does not have permission to accept a connec‐
105 tion on the responding transport endpoint or to use
106 the specified options.
107 TBADADDR The specified protocol address was in an incorrect
110 format or contained illegal information.
111 TBADDATA The amount of user data specified was not within the
114 bounds allowed by the transport provider.
115 TBADF The file descriptor fd or resfd does not refer to a
118 transport endpoint.
119 TBADOPT The specified options were in an incorrect format or
122 contained illegal information.
123 TBADSEQ Either an invalid sequence number was specified, or a
126 valid sequence number was specified but the connection
127 request was aborted by the peer. In the latter case,
128 its T_DISCONNECT event will be received on the lis‐
129 tening endpoint.
130 TINDOUT The function was called with fd==resfd but there are
133 outstanding connection indications on the endpoint.
134 Those other connection indications must be handled
135 either by rejecting them by means of t_snddis(3NSL)
136 or accepting them on a different endpoint by means of
137 t_accept.
138 TLOOK An asynchronous event has occurred on the transport
141 endpoint referenced by fd and requires immediate
142 attention.
143 TNOTSUPPORT This function is not supported by the underlying
146 transport provider.
147 TOUTSTATE The communications endpoint referenced by fd or
150 resfd is not in one of the states in which a call to
151 this function is valid.
152 TPROTO This error indicates that a communication problem has
155 been detected between XTI and the transport provider
156 for which there is no other suitable XTI error
157 (t_errno).
158 TPROVMISMATCH The file descriptors fd and resfd do not refer to the
161 same transport provider.
162 TRESADDR This transport provider requires both fd and resfd to
165 be bound to the same address. This error results if
166 they are not.
167 TRESQLEN The endpoint referenced by resfd (where resfd != fd)
170 was bound to a protocol address with a qlen that is
171 greater than zero.
172 TSYSERR A system error has occurred during execution of this
175 function.
176
179 The XTI and TLI interface definitions have common names but use differ‐
180 ent header files. This, and other semantic differences between the two
181 interfaces are described in the subsections below.
182 Interface Header
184 The XTI interfaces use the header file, xti.h. TLI interfaces should
185 not use this header. They should use the header:
186 #include <tiuser.h>
188 Error Description Values
191 The t_errno values that can be set by the XTI interface and cannot be
192 set by the TLI interface are:
193 TPROTO
195 TINDOUT
198 TPROVMISMATCH
201 TRESADDR
204 TRESQLEN
207 Option Buffer
210 The format of the options in an opt buffer is dictated by the transport
211 provider. Unlike the XTI interface, the TLI interface does not specify
212 the buffer format.
213
215 See attributes(5) for descriptions of the following attributes:
216 ┌─────────────────────────────┬─────────────────────────────┐
221 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
222 ├─────────────────────────────┼─────────────────────────────┤
223 │MT Level │Safe │
224 └─────────────────────────────┴─────────────────────────────┘
225
227 t_connect(3NSL), t_getinfo(3NSL), t_getstate(3NSL), t_listen(3NSL),
228 t_open(3NSL), t_optmgmt(3NSL), t_rcvconnect(3NSL), t_snddis(3NSL),
229 attributes(5)
230
232 There may be transport provider-specific restrictions on address bind‐
233 ing.
234 Some transport providers do not differentiate between a connection
237 indication and the connection itself. If the connection has already
238 been established after a successful return of t_listen(3NSL),
239 t_accept() will assign the existing connection to the transport end‐
240 point specified by resfd.
241SunOS 5.11 1 May 1998 t_accept(3NSL)